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abstract 


Tnis  tnesls  presents  tne  specification,  desig'-  anc 
implementation  of  a  prototype  microcomputer  system  for  tne 
target  information  section  of  tne  Marine  Corps  fire  support 
coordination  -'enter.  Currently,  tne  target  information 
section  uses  a  series  of  index  cards,  Handwritten  lists, 
acetate  covered  battle  maps  and  grease  pencils  to  perform 
tne  target  information  functions. 

Tne  tnesls  examines  and  analyzes  tnese  functions  in 
detail  and  proposes  a  solution  in  tne  form  of  a  system,  data 
Dase  and  interactive  user  design.  Tne  resultant 
,MIcrocompute r  System,  for  Target  Information  (MISTH  employs 
an  ALTOS  Z-32  microcomputer,  tne  'JCSD  Pascal  operating 
system,  a  user  friendly  interface  and  data  Dase  technology. 
It  is  proposed  as  an  interim  system  until  tne  varir.e 
Integrated  Fire  and  Air  Support  System  (MIFASS'  becomes 
operational. 
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I.  INTRODUCTION 


A.  THE  PROBLEM 

More  and  more  of  tne  applications  of  modern  amphibious 
warfare,  from  real-time  combat  systems  to  tne  data  oases 
that  control  the  men,  materiel  and  resources  needed  to  wage 
war,  nave  turned  to  computerized  solutions.  The  products  of 
the  technological  explosion  nave  enabled  the  Navy-Marine 
Corps  amphibious  team  to  do  more,  to  do  it  faster  and  to  do 
it  with  a  degree  of  efficiency  and  accuracy  previously 
unobtainable . 

This  evolution  of  modern  tecnnology  nas  not  yet  reached 
the  Marine  Corps  tactical  command  posts  established  on  the 
beachhead.  The  target  information  section  of  tne  landing 
force  fire  support  coordination  center  (FSCC)  plays  a 
slgnficant  role  in  tne  conduct  of  effective  coordination  of 
tactical  air,  artillery  ana  naval  gunfire  support  on  targets 
of  high  priority,  let  the  target  information  officer  and  nis 
staff  accomplish  their  important  tasic  by  the  use  of  index 
card  files,  cross-reference  files,  hand  written  lists  of 
targets  and  colored  grease  pencils  on  acetate-covered 
tactical  maps.  This  method  is  time  consuming,  slow  in 
response  to  inquires  about  target  information,  tedious  and 
difficult  to  maintain  in  a  current  status  and  does  not 
provide  information  in  a  sufficiently  timely  and  accurate 
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manner.  It  is  40  year  oil  technology  in  tne  age  of 
computers. 

Tne  requirement  to  automate  many  of  tne  functions  of  tne 
tactical  command  post  nas  been  identified  and  tne  command 
post  of  the  future  is  bein?  planned  for  and  developed  no w. 
Until  it  arrives,  tftere  is  a  need  to  provide  an  interim 
capability  to  tne  laniine  force.  An  automated  solution  to 
tne  target  information  function  will  simplify  tne  tasic  of 
tne  target  information  section  considera bly ,  will  provide 
rapid,  accurate  and  timely  target  information  to  tne  members 
of  the  FSCC,  and  can  be  made  operational  now,  five  full 
years  before  tne  planned  introduction  of  tne  computerized 
command  post. 

Tnis  tnesis  contends  tnat  tne  automation  of  tne  target 
information  function  is  necessary  to  improve  tne  operational 
capability  of  tne  landing  force  FSCC  and  tnat  implementation 
of  a  suitable  and  effective  tareet  information  system  is 
possible.  Tnis  tnesis  will  prove  tnis  contention  by 
implementing  and  designing  a  working  prototype  wnica  will 
increase  operational  effectiveness  immediately  as  well  as 
provide  a  testbed  and  learning  model  for  tne  future 
automated  command  post.  The  prototype  will  be  designed  to 
perform  all  tne  duties  and  functions  of  tne  target 
information  section  as  currently  stated  In  doctrinal 
publications.  The  interim  system  will  hopefully  contribute 
to  the  development  of  tne  future  system  and  identify  areas 
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of  concern  and  improvement  before  tne  future  Marine  Corps 
system  becomes  operational. 

fl.  BACKGROUND 

An  important  aspect  of  ampniblous  fire  support 
coordination  (tne  planning  and  execution  of  tactical  air, 
artillery  and  naval  gunfire  support  so  trial  targets  are 
adequately  covered  by  a  suitable  weapon  or  group  or  weapons) 
is  tne  function  of  target  information.  One  of  tne  major 
duties  of  tne  fire  support  coordinator,  tnat  member  of  tne 
landing  force  staff  responsible  for  coordination  of  fire 
support,  is  to  ensure  tnat  tne  fire  support  coordination 
center  receives  and  disseminates  available  target 
information  to  all  staff  sections  and  commands  requiring  tne 
information.  He  also  must  work  closely  vitn  tne  target 
Information  officer  and  tne  commander  and  nis  staff  in  tne 
selection  of  targets  and  assignment  of  classification  and 
attack  priorities. 

Target  Information  is  tne  direct  application  of  combat 
Intelligence  to  fire  support  and  is  a  Key  to  tne  proper 
employment  of  supporting  arms  in  conjunction  with  earn  of 
tne  plans  of  the  ampniblous  operation.  Effective  fire 
support  coordination  and  tne  planning  of  ampniblous 
operations  generate  a  continuing  requirement  for  target 
acquisition,  dissemination,  evaluation  and  recommendation 
for  attack. 
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To  accomplish  this  important  tass,  the  commander  of  tne 
amphibious  taste  force  assigns  a  target  intelligence  officer 
to  the  supporting  arms  coordination  center  (SACC).  This 
officer  operates  tne  target  information  center  (TIC)  and 
worrs  closely  with  the  air  intelligence  officer,  tne  landing 
force  targeting  representatives  and  the  supporting  arms 
coordinator.  The  commander  of  the  landine  force  has  a  target 
information  officer  (T 1 0 )  wno  operates  tne  target 
information  section  (TIS)  as  an  integral  part  of  tne  landing 
force  fire  support  coordination  center  and  a  target 
intelligence  officer  who  functions  in  tne  landing  rorce 
Intelligence  center. 

The  Navy  staff  uses  a  computerized  target  information 
system  wnlcn  is  part  of  tne  shipboard  Amphibious  Support 
Information  System  (ASIS)  and  maintains  the  list  of  targets 
as  part  of  a  data  base.  Target  information  operations  in  tne 
SACC  are  thus  computerized  and,  while  tne  ASIS  target  system 
is  not  tne  most  modern  of  data  base  systems,  it  is 
efficient,  effective  and  fast.  «fhen  the  functional 
responsibility  for  maintaining  targets  is  passed  ashore  to 
the  landlnsr  force  TIO,  the  computer  system  is  replaced  by  an 
index  card  filing  system,  wnicn,  while  effective,  is  neither 
fast  nor  efficient  by  comparison.  Additionally,  the  index 
card  system  lends  itself  to  inaccuracies  and  omissions  in 
target  data,  particularly  when  the  information  must  be 
maintained  in  a  timely  manner.  The  tactical  requirement  for 
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accurate  and  timely  target  information  is  no  less  critical 
or  Important  when  the  landing  force  is  on  tee  beacn,  yet  tne 
system  to  accomplisn  tais  tass  is  antiquated  and  cumbersome. 

The  staff  of  the  TIS  manually  transfers  the  target 
information  lata  contained  in  tne  ASIS  data  base  to  5  ty  9 
inch  target  cards.  After  duplicating  the  entire  target  file, 
tne  TIS  must  construct  a  cross  reference  file  to  list  tne 
target  by  grid  location  and  a  cross-index  file  to  Keep  trade 
of  certain  types  of  targets.  In  addition  to  tne  target 
cards,  the  TIS  also  maJces  up  lists  of  particular  categories 
of  targets  wnlcn  may  be  of  interest  or  value  to  members  of 
the  FSCC. 

The  TIS  obtains  <ntellieence  information  from  landln* 
force  and  supporting  arms  agencies,  converts  tais  to  target 
information  and  enters  the  information  into  the  tareet  card 
files.  The  information  is  made  available  to  tne  supporting 
arms  representatives  in  the  FSCC  and,  based  on  the  TIO's 
recommendations,  a  decision  is  made  when  ana  now  to  attacic  a 
Darticular  tareet.  Results  or  attacss  on  targets,  front  line 
reports  and  intelligence  information  are  used  to  refine  tne 
tarsret  list  and  delete  or  deprioritize  those  targets  that 
present  a  diminished  tnreat  to  tne  landing  force. 

Access  to  specific  information  from  the  tareet  list  (fer 
example,  more  than  one  category  of  tne  cross-index  files) 
requires  physically  searching  tnrouen  each  list  and 
constructing  sub-lists  to  determine  tne  appropriate 
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timely  and 


Information.  Tne  constant  availability  of 
accurate  target  information  is  reouired  for  tee  effective 
employment  of  supporting  arms  and  planning  of  fire  support. 
Tne  TIi  plays  a  Key  role  in  providing  tnis  information  and 
tne  constant  process  of  adding  to  tne  target  list,  selecting 
targets  for  attacK  and  deleting  targets  once  neutralized  is 
performed  oy  tne  TIS  staff  using  tne  target  card  file. 

C.  INTEGRATED  FIRE  AND  AIR  SUPPORT  SISTB* 

One  of  tne  most  complex  asoects  of  modern  ampniblous 
warfare  is  tne  control  and  coordination  of  supporting  arms 
Darticularly  in  tne  transition  of  responsi oility  from  tne 
Navy  in  ampniblous  snips  to  tne  Marine  Corps  combat  units 
asnore.  The  crease  pencils,  map  boards  and  field  radios  tnat 
nave  served  Marines  so  well  since  tne  days  of  Guadalcanal 
will,  in  tne  future,  be  eclipsed  by  tne  automated  system 
called  tne  Marine  Integrated  Fire  and  Air  Support  System 
(MIFASS). 

MIFASS  is  part  of  tne  Marine  Corps  integrated  command 
and  control  system  called  MTACCS  (Marine  Tactical  Command 
and  Control  Systems),  a  collection  of  eignt  major  systems 


wnicn  win  give 

tne 

Marines 

a 

capability  of  exercising 

real-time 

command 

and 

control 

of 

combat  forces  in  tne 

pos  t-1980 

time 

frame . 

MIFASS 

is 

designed  to  perform  tne 

functions  of  tne  fire  support  coordination  center,  (FSCC^ 
tne  direct  air  support  center  (DASC)  and,  to  a  degree,  tne 


artillery  fire  direction  center  (FDC)  at  one  central 
location  called  tne  Fire  and  Air  Support  Center  (FASC1. 

It  is  a  distributed  processing  system  in  whi~n 
microcomputers  control  Interactive  display  devices,  manage 
data  bases,  perform  computational  tasics  and  drive  printers 
to  provide  nard-copy  records  of  messages  ana  operator 
decisions.  It  is  currently  in  full  scale  engineering 
development  witn  an  initial  operational  capability  planned 
for  tne  1986-198?  time  frame.  MIFASS  addresses  tne 
requirement  for  target  information  by  providing  tne  TIO  witn 
a  digital  display  device  wnich  will  nave  botn  a  grapnical 
representation  of  tne  target  on  a  battle  map  and  a  video 
screen  for  aipnanumeric  display  of  target  information. 

D.  NATURE  OF  THE  PHOB1EM 

An  automated  solution  to  tne  target  information  function 
will  not  be  realized  until  tne  introduction  of  tne  MIFASS 
computers  into  tne  Fleet  Marine  Forces.  Until  sucn  time  as 
tbe  system  is  delivered,  tne  target  information  function  of 
tne  FSCC  is  tied  to  tne  current  doctrine  and  tne  target  card 
filing  system. 

In  this  report,  an  interim  systems  solution  to  tne 
problem  of  automating  tne  target  information  function  of  tne 
FSCC  is  presented.  It  computerizes  those  basic  functions  of 
tne  TIS  in  a  simple,  inexpensive  and  effective  manner.  It 
simplifies  tne  tasss  of  the  TIS,  provides  a  mechanism  for 
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rapid  and  accurate  retrieval  of  target  information  ana  couia 
improve  ttie  operational  capability  of  tfte  FSCC. 

2.  NATCT5B  OF  THE  SOLUTION 

Tne  amount  of  target  information  tnat  needs  to  be 
processed  is  sufficiently  small  tnat  a  microcomputer  is  tne 
most  suitable  piece  of  Hardware  for  implementation.  Tne 
current  versions  of  microcomputers  are  very  versatile  witn 
efficient  operating  systems,  various  input/output  media 
including  video  terminals,  inexpensive  and  relatively 
portable  secondary  storage  media  (floppy  diskettes  and 
cassettes),  nign  level  language  programming  capabilities  and 
even  scaled  down  versions  of  data  base  management  systems. 
Tnus,  tne  tecnnology  in  nardware  as  well  as  software 
currently  exists  in  tne  commercial  marketplace  and  it  is 
possible  tnat  a  practical  system  can  result  from  efficient 
and  careful  design  and  implementation. 

Tde  design  task  is  broken  down  into  tnree  distinct 
parts,  eacn  of  wnicn  is  influenced  by  tne  overall  design 
cnaracterlstics  and  is  individually  addressed  in  separate 
ctapters . 

Tne  design  of  tne  pnysicai  and  logical  data  base  is 
influenced  by  tne  desire  to  nave  a  simple  yet  sufficiently 
Informative  data  model,  a  rapid,  real-time  response  and  a 
restricted,  single  application  system.  Tne  system  design  is 
influenced  by  tne  microcomputer  environment  wnicn  restricts 
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tne  user  bo tn  in  main  memory  space  and  tne  speed  of  access 
lo  secondary  storage  and  the  requirement  for  an  effective 
interactive  system  for  a  non-sophi sticated  user. 

The  design  of  tne  software  to  implement  both  tne  data 
base  and  the  system  is  overwhelmingly  influenced  by  tne 
requirement  that  the  system  support  real-time,  interactive 
processing  of  a  casual,  non-programmer .  Termed  "Marine 
proof"  in  the  vernacular,  it  reouires  a  sophisticated 
interface  employing  user  friendly  dialogue  techniques  to 
ensure  that  the  operation  is  simple  and  efficient.  For  this 
reason,  and  to  facilitate  system  portability,  a 
microcomputer  compatable  high  level  programming  language  is 
employed  In  implementation. 

In  order  to  better  identify  the  user  environment  and  to 
obtain  an  understanding  of  the  functions  of  target 
information,  the  next  chapter  describes  tne  mission  and  the 
current  procedures  or  the  target  information  section.  It  is 
from  tnis  information  that  the  system  characteristics  were 
developed  and  the  design  based.  The  information  was  obtained 
from  Navy  and  Marine  Corps  doctrinal  publications  as  well  as 
current  operating  procedures  of  a  Marine  Division  target 
Information  section.  Chapters  III  through  VI  develop  in 
detail,  the  reasons  for  the  parameters  selected  and  the 
decisions  made  in  tne  design  of  tne  overall  system,  tne 
logical  and  physical  data  base  and  the  applications 
software. 
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Caapter  VII  addresses  tae  implementation  of  tne  system 
and  further  implications  of  system  application  in  the  Marine 
Corps,  as  well  as  tactical  employment  and  interface  with 
current  and  future  systems.  Conclusions  and  recommendations 
are  included  in  tne  last  caapter. 

The  source  code  listing,  wnich  has  been  developed  as  a 
result  of  tnis  thesis,  nas  been  published  as  a  Naval 
Postgraduate  School  technical  report  entitled  A  Prototype 
Program  for  Target  Information  (NPSbid-8l-£fc:7) .  A  data 
dictionary  and  an  example  of  the  system  Interface  are 
included  in  tne  appendices.  A  bibliography  of  applicable 
references  and  a  list  of  abbreviations  used  are  also 
included . 


II .  TARGET  INFORMATION  PROCEDURES  AND  EMFLQIMSNT 

A.  GENERAL 

A  precise  understanding  of  the  duties  of  tne  target 
information  officer  and  procedures  used  oy  tne  target 
information  section  is  required  Before  detailed  requirements 
for  an  automated  target  information  system  can  be  statei. 
Tnis  cnapter  is  devoted  to  tnat  purpose.  It  discusses  and 
examines  in  detail  tne  doctrinal  duties  and  functions  of  tne 
target  information  officer  and  tne  current  procedures  for 
executing  tnese  functions. 

The  tareet  information  officer  is  a  member  of  the  fire 
support  coordination  center  (ESC C).  He  and  nis  staff  provide 
target  information  to  the  fire  support  coordinator  so  that 
effective  employment  of  supporting  arms  is  driven  by  timely 
and  accurate  target  intelligence.  He  works  directly  vitn  tne 
artillery  representatives,  tne  air  officers  and  tne  naval 
gunfire  support  officers  in  aiseminating  appropriate  target 
Information  and  obtaining  surveillance  information.  He 
assigns  battle  damage  assessments  for  attacked  targets  and 
further  refines  the  target  list. 

His  relationship  with  both  tne  amphibious  task  force 
target  intelligence  officer  and  tne  landing  force  target 
intelligence  officer  is  extremely  important  since  it  is  from 
these  sources  that  ne  obtains  the  target  intelligence  which 
generates  the  target  information. 
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J8.  DUTIES  OF  THE  TARGET  INFORMATION  OFFICER 


The  TIO  is  a  Marine  Corps  officer  vno  performs  nis 
duties  under  trie  staff  cognizance  or  tne  fire  support 
coordinator  (FSC)  and  worics  closely  with  tne  lancing  force 
ODerations  and  intelligence  sections.  Tne  primary  doctrinal 
puolication  for  tne  Marine  Corps  is  Fleet  Marine  Foroe 
Manual  (FMFM)  7-1  (Fire  Support  Coordination'  »nicn  outlines 
nis  duties  as  follows: 

1.  Seeping  tne  FSC  and  tne  otner  fire  support 
representatives  in  tne  FSCC  informed  of  tne  status  of 
targets . 

2.  Ensuring  tnat  pertinent  target  intelligence  is  posted 
on  tne  FSCC  target  and/or  situation  maps. 

3.  Preparing  and  maintaining  target  file  carls. 

4.  Entering  target  attach  evaluations  and  surveillances 
on  the  target  cards. 

5.  Supervising  the  operation  of  tne  target  information 
section  ( T I S  )  of  tne  FSCC. 

5.  Preparing  tne  landing  force  list  of  targets  or  tne 
Marine  air-ground  tasi  force  (MACTF)  target  list  for 
promulgation  by  tne  operations  officer.  Tne  FSCC  will 
provide  targets,  to  include  tnsir  classification  ar.d 
priorities,  wnicn  are  to  be  included  in  tne  target  list, 
target  bulletins  and/or  lists  of  targets. 

7.  Preparing  and  releasing  target  bulletins  when  control 
of  tne  target  list  nas  seen  passed  to  tne  commander 
landing  force  or  wnen  tne  MASTF  is  engaged  in  land 

warfare . 

S.  Keeping  tne  target  intelligence  officer  advised  of 
target  information  available  tnrougn  supporting  arms 
sources. 


C.  FUNCTION  S  OF  THE  TAP.SET  INFORMATION  SECTION 


Tne  functions 

of  t  ne 

Tib  are 

oriented  to 

tne 

requirements  of  tne 

supporting 

a  r.m  s  (air. 

naval  gunfire 

and 

artillery)  in  tne  preparation  of  fire  support  plans  and  me 
command  requirements  for  target  information.  Tne  TIS  uses 
all  of  tne  available  intelligence  gatnerea  by  tne  agencies 
of  tne  ampnibious  tass  force  and  tne  landing  force.  Tnese 
agencies  include  landing  force  and  ampnibious  tasic  force 
target  intelligence  sections  and  intelligence  agencies  of 
tne  supporting  arms. 

Tne  TIS  is  responsible  for  recording  all  target 
information,  analyzing  tnis  target  Information,  maintaining 
records  and  mating  recommendations  of  targets  wnic.n  are 
appropriate  for  attacic.  FMFM  7-1  lists  tne  following 
functions  of  tne  TIS: 

1.  Maintaining  required  target  ana  situation  maps. 

Z .  Maintaining  target  cards  and  target  files,  including 
cross-indexed  files  of  target  information. 

3.  Consolidating,  evaluating  and  displaying  target 
information. 

4.  Recommending  classification  and  attacg  priorities  to 
tne  FSC . 

5.  Collecting  from  all  agencies  and  sources,  any 
information  pertaining  to  tne  results  of  attacic  on 
targets  by  tne  supporting  arms. 

6.  Consolidating  and  evaluating  results  of  attacks  by 
tne  individual  supporting  arms  and  tne  metnods  of 
attacic,  and  recommending  additional  measures  tnat  appear 
necessary  from  tne  overall  results  and  analyses. 
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7.  Coordinati ng  on  ail  matters  witr.  tne  landing  force 
target  intelligence  officer  and  tne  artillery  unit 
intelligence  officer  for  target  and  counterfire 
information  and  correlation  of  records  and  files. 

9.  Maintaining  current  counterfire  target  lists  to 
include  counter-mortar,  counter-battery  and  SEAT 
(suppression  of  enemy  air  defense)  lists  and  providing 
tnis  Information  to  tne  supporting  arms  representatives 
as  well  as  ensuring  dissemination  to  tne  landing  force 
as  a  waole. 

y.  Preparing  and  disseminating  target  bulletins 
(TaRBIL's)  after  control  of  tne  target  list  nas  been 
passed  asnore. 

10.  Maintaining  a  nuclear  and  cnemicai  target  foiaer  to 
assist  in  tne  selection,  evaluation  ana  planning  of 
attacic  by  supporting  arms  utilizing  nuclear  and  cnemicai 
munitions. 

Tne  composition  and  organization  of  tne  TIS  varies  wita 
tne  FSCC  level  out  typically  at  tne  landing  force  level  it 
consists  of  one  officer  (TIO)  and  from  one  to  tnree  enlisted 
personnel.  Personnel  are  usually  trained  in  target 
intelligence,  supporting  arms  capabilities  and  limitations, 
organization,  fire  support  coordination  principles  and 
communications . 

While  tne  functions  and  duties  of  target  information 
personnel  are  determined  by  tne  doctrinal  publications,  tne 
actual  procedures  to  accomplisn  tnese  functions  will  differ 
sligntly  from  one  organization  to  anotner,  nowever  tnese 
variations  are  minor. 


D.  TARGET  INFORMATION  RECORDS  AN D  FILES 


Tiie  records  and  files  of  tareet  information  consist 
primarily  of  situation  maps,  target  file  cards,  target  lists 
and  cross-indexing  files  at  tne  landing  force  level.  Tney 
are  tne  tools  used  to  catalogue,  analyze  and  disseminate 
target  information. 

Tne  target  map  provides  a  visual  reference  of  targets 
appropriate  for  attacs  by  supporting  arms.  Tne  friendly 
situation  map  contains  all  information  pertinent  to 
supporting  arms  operations  ana  typically  includes 
objectives,  front  lines,  fire  support  control  measures,  unit 
boundaries  and  unit  locations. 

Tne  buis  of  tne  record  seeping  involves  tne  target  file 

card.  The  file  of  b  by  b  inch  cards  contains  a  separate 

target  card  for  eacn  fcnown  or  suspected  target  ootn  by 

tareet  number  and  by  arid  coordinates.  Fleure  1  is  an 

example  of  a  target  card.  Information  appearing  on  tee 

target  card  includes  the  foliowine: 

target  symbol  (conventional  map  symbol) 

tareet  number 

target  classification 

attacs  priority 

target  location  (grid  coordinates) 
tareet  elevation  in  meters 
map  reference 
tareet  description 

assignment  of  supporting  arms  attacs  means 
source  and  date  of  target  information 
ptiotoerapn  number  and  arid  location 
remarss  of  additional  significance 
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Figure  1. 

Sxarpi?  of  a  Target  Care. 

• 

Tne  target  cross-index  file  consists  of  one  card  or  list 
for  each  type  of  target  (e.g.,  counter-battery,  armor,  Si’AD, 
fortification,  etc.).  Eacn  card  or  list  typically  includes 
only  tne  tareet  numDer  of  eacn  target*  it's  priority,  tr.e 
recommended  metnod  of  attacK  ana  tne  final  disposition  of 
tr.e  target. 


In  a 

typical 

ampni tious 

ope 

ration , 

tne  landing  force 

usually 

operates  witn  a 

maximum  of 

approximately  200-500 

targets . 

irfitn  a 

separate  target 

card 

for  eacn  target  by 

tareet 

num  oer 

as  well 

as 

Dy  *ri 

i  coordinate  and  a 

cross-index  card  for  tae  10  to  15  target  types,  tne  target 
file  can  easily  exceed  500  caras.  An  example  of  a  Marine 
division  target  card  file  organization  is  illustrated  in 
figure  2. 


ACTIVE  TARGETS  INACTIVE  TARGETS 


Figure  2.  Target  Card  File  Organization. 
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THE  TARSET 


LIST 
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i  • 

A  semantic  distinction  must  be  made  between  me  "target 
list"  and  the  ’’list  of  targets”.  The  "target  list"  is  a 
collection  of  targets  wnica  is  maintained  ana  promulgated  by 
tne  senior  echelon  of  command.  There  is  only  one  "target 
list".  It  contains  targets  wnica  are  pertinent  to  tne 
landing  force  as  a  wnole  and  which  are  to  be  taicen  under 
attacfc  by  supporting  arms.  A  "list  of  targets"  is  maintained 
at  any  echelon  of  command  and  includes  tnose  confirmed, 
suspected  or  possible  targets  for  information  ana  planning 

purposes  as  well  as  for  possible  attacic  by  supporting  arms. 


The  "target  list"  is  a 

subset  of 

tne 

"list  of 

targets" . 

Subordinate  units 

use  the 

target  list 

as  tneir  basic 

source  of  targets  and 

also  include 

targets 

that  have  a 

significant  but  specific  or  "short-life"  value  to  their 
operations  in  their  unit  list  of  targets.  As  an 
illustration,  a  battalion  would  only  include  tnose  targets 
from  tne  landing  force  target  list  wnich  were  located  in  or 
adjacent  to  tneir  zone  of  action. 

Targets  can  be  furtner  described  as  active  or  inactive. 
An  active  target  is  one  wnich  is  on  tne  target  list  or  list 
of  targets  and  presents  a  Donafide  current  or  future  enemy 
capability  to  interfere  with  operations.  An  inactive  target 
is  one  wnicn  nas  been  overrun  by  friendly  forces  or 
destroyed  by  supporting  arms  or  nas  shown  no  activity  for  7'd 
nours  and  no  damage  assessment  nas  been  made,  although  these 
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latter  targets  are  inactivated  vitn  caution.  Tne  inactive 


targets  are  placed  in  a  deadflle  and  reactivated  if 
necessary.  Figure  3  depicts  tne  target  list  terminology. 


ACTIVE  TARGETS  INACTIVE  TARGETS 


Figure  3.  Target  List  Terminology. 

F.  TARGET  CLASSIFICATION 

Targets  are  classified  Dy  tne  effect  vnica  tneir 
existance  or  elimination  may  nave  on  tne  ampnibious  tasic 
force  and  by  restrictions  imposed  by  the  commander  on  tne 
attacfc  of  certain  targets. 

The  primary  doctrinal  publication  for  ampnibious 
warfare*  NtfP  22-2  (Supporting  Arms  in  Ampnibious  Operations) 
list  tne  following  target  classifications: 

Class  A. ..Targets  mat  threaten  snips,  aircraft, 
minesweeping  and  underwater  demolitions 
operations . 

Class  B.. .Targets  tnat  threaten  assault  forces  in  tne 
snip-to-snore  movement  and  assault  of  tne 
beacn . 

Class  C.. .Targets  tnat  tnreaten  or  oppose  landing  force 
operations  afterlanding  or  affect  tne  ability 
of  tne  enemy  to  continue  resistance. 
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Class  D. ..Targets  tnat  will  not  be  fired  on  prior  to 
D-Day . 

Class  E...Tar*ets  tnat  must  not  be  destroyed  (unless 
specific  orders  for  sucn  destruction  are 

issued  by  tne  amphibious  tass  force  or  landing 
force  commander)  eltner  because  of  probable 
future  use  by  our  own  forces  or  for 

humanitarian  reasons.  These  Installations  may 
be  neutralized,  harassed  or  interdicted  if 
prior  approval  is  obtained  from  tne  commander 
imposing  tne  restrictions. 

G.  TARGET  PRIORITY 

The  target  information  officer,  m  coordination  wltn  tne 
target  Intelligence  officer,  tne  fire  support  coordinator 
and  tne  supporting  arms  representatives  reviews  and 
recommends  the  assignment  of  attactc  priority.  Tne  target 
priority  Is  established  to  determine  tne  sequence  of  attacic 
and/or  the  effort  to  be  allocated  to  a  eiven  target.  Tne  TIO 
establishes  tne  priority  based  on  tne  target's  effect  on  tne 
accomplishment  of  the  landing  force  mission  and  its  relative 
importance  as  compared  to  other  targets. 

F!iF?1  7-1  lists  the  following  tareet  priorities: 

Priority  I . Targets  capable  of  preventing  tne 

execution  of  the  plan  of  action  by  tne 
landine  force  and  its  elements. 

Priority  II ... .Targets  capable  of  immediate  serious 
interference  with  the  plan  of  action  of  the 
landing  force  and  its  elements. 

Priority  III. .  .Targets  capable  of  ultimate  serious 
interference  with  tne  plan  of  action  of  tne 
landing  force  and  its  elements. 

Priority  17. .. .Targets  capable  of  limited  interference 
with  tne  plan  of  action  of  tne  landing 
force  and  its  elements. 
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H.  THE  TARGET  BULLETIN 

In  order  to  maintain  up-to-date  target  information 
records,  it  is  essential  that  reports  of  tne  discovery  of 
new  targets  and  the  analysis  of  supporting  arms  attacks  on 
existing  targets  be  reported  to  the  appropriate  units.  Tne 
TIO  evaluates  and  consolidates  reports  of  target  information 
and  supporting  arms  battle  damage  assessment  (EDA)  and 
prepares  a  target  bulletin  (TARBQL).  Upon  approval,  it  is 
released  to  interested  commanders  of  nigner,  lower  and 
adjacent  elements  of  the  amphibious  tasx  force. 

The  TARBOL  is  normally  transmitted  over  existing 
teletype  or  radio  circuits  and  typically  adds  new  targets  to 
tne  target  list  (giving  tne  target  number,  location, 
elevation,  priority,  classification  and  description),  gives 
damage  assessment  to  existing  targets  wnicn  nave  been 
attached  by  supporting  arms,  canceils  targets  from  the 
target  list  (relegating  tnem  to  tne  deadfile)  and 
reactivates  previously  cancelled  targets.  TARBUL's  are 
serialized  and  issued  on  an  as-needed  basis. 

I.  OPERATIONS  OF  THE  TARGET  INFORMATION  SECTION 

While  tae  target  information  section  is  neaviiy  involved 
in  the  early  phases  of  the  operation,  the  most  important 
witn  respect  to  tnls  tnesis  occurs  during  tne  preparation  of 
the  objective,  ship-to-snore  movement  and  operations  ashore. 
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The  target  list  Is  initaily  maintained  by  the  SACC 
tareet  intelligence  officer.  Tne  tareet  information  is 
stored  in  a  data  base  of  tne  ASIS  system  and  a  navy  computer 
operator  wortin*  in  the  SACC  operational  spaces  uses  tne 
QUEST  data  base  query  language  to  access  targets  and  target 
information  from  tne  data  base.  Requests  for  a  target 
listing  and  for  special  purpose  reports  must  oe  composed  in 
the  query  lan*uaee  each  time.  Response  to  the  query  is 
displayed  on  a  video  display  unit  in  tne  SACC.  Tne  report 
printouts  are  available  from  a  printer  located  in  the  main 
computer  spaces. 

During  this  period,  tne  TIO  is  monitoring  and 
duplicating  tne  target  list  witn  tne  target  card  files.  It 
typically  is  an  opportunity  for  the  TIS  staff  to  become  very 
familiar  witn  tne  target  card  file  procedures,  aitnougn  it 
requires  almost  a  complete  duplication  of  effort  between  tne 
TIC  and  tne  TIS. 

When  tne  TIS  goes  ashore  witn  tne  landing  force  FSCC, 
they  obtain  computer  printed  copies  of  tne  latest  tareet 
list  as  a  backup  to  tnelr  card  file.  Cnanges  to  tne  target 
list  during  the  phasing  of  the  TIS  asnore  are  covered  Dy  a 
TARBUl  issued  by  tne  commander  ampnibious  tasK  force. 

Operations  ashore  are  characterized  by  constant 
refinement  of  tne  target  list,  adding  newly  acquired  targets 
and  tne  employment  of  supporting  arms  on  existing  targets. 
Wnen  target  Information  is  received,  tne  target  is  plotted 


34 


on  the  target  flap,  a  classification  assignee,  a  target  card 
prepared  and  all  available  information  evaluated.  A  priority 
of  attact  is  assigned  and  a  recommendation  regarding  attacs 
by  supporting  arms  is  made.  The  tarset  card  is  then  added  to 
tne  target  number  file,  tne  grid  location  file  and  tne 
cross-index  file  if  necessary. 

As  fire  support  missions  are  executed,  tne  TIS  attempts 
to  expedite  the  surveillance  reports  from  the  available  fire 
support  sources.  A  damage  assessment  is  made  based  on  tne 
reported  surveillance.  The  information  is  added  to  the  tact 
of  the  target  card  and  the  target  is  updated  as  required. 
The  primary  sources  of  this  information  are  artillery 
forward  observers,  naval  gunfire  spotters,  forward  air 
controllers  and  liaison  officers. 

New  targets  are  reported  to  tne  landing  force  TIS  from 
the  target  information  sections  of  subordinate  units  who 
nave  uncovered  targets  of  sufficient  importance  to  be 
recommended  for  Inclusion  on  the  target  list.  Targets  are 
also  received  from  tne  target  intelligence  officer,  tne 
artillery  tareet  acquisition  battery  and  acoustic  and 
seismic  sensors.  Based  on  tne  accuracy  of  this  information 
(confirmed,  probable,  possible  or  unknown),  a  determination 
is  made  wnetner  to  add  tne  target  to  tne  target  list,  tne 
list  of  targets  or  the  Inactive  file. 
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J.  OPERATIONAL  CHARACTERISTICS 


Th?  operations  of  tne  TIS  focus  on  two  major  functions* 
tne  maintenance  of  tne  target  card  file  and  tne  grapnical 
representation  of  tne  target  information  on  tne  target  map. 
Tne  former  function  appears  to  lend  itself  to  an  effective 
automated  solution.  Tne  following  items  are  tne  significant 
recurring  requirements  for  maintenance  of  tne  target  card 
file: 

adding  a  target  to  tne  file 
deleting  a  target  from  tne  file 
changing  information  about  a  target  in  tne  file 
cnanging  tne  status  of  a  target  (active-inactive) 
updating  tne  cross-index  file 

Tne  products  of  tnis  maintenance  are  used  by  tne  TIO  and 

tne  staff  of  tne  FSCC  for  effective  fire  support 

coordination  and  delivery  of  supporting  arms.  An  analysis  of 

these  products  indicate  that  tne  target  card  file  provides 

the  following  specific  capabilities: 

provides  all  target  information  for  a  specific  target 

differentiates  between  active  and  inactive  targets 

sorts  or  catalogues  targets  oy  various  parameters  (wnicn 
Include  target  no.,  coordlrates,  classification, 
priority,  target  type,  supporting  arm  assigned  and 
target  accuracy) 

provides  information  upon  which  to  base  a  TARBUL 
provides  Information  for  production  of  tne  target  list 
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K.  SUMMARY 

The  organization  examined  in  this  chapter  is  for  the 
landing  force  target  information  section  (TIS)  (typically  a 
Marine  division  or  a  Marine  ampniDious  brigade)  wnica 
constitutes  tne  most  important  and  most  heavily  staffed 
section.  The  TIS  exists  at  regimental  and  battalion  level  as 
well,  but  with  less  formality.  Tne  card  file  is  not  as 
extensive  (due  to  the  fewer  number  of  targets  in  tne  zone  of 
action  of  a  smaller  unit)  and  tne  target  personnel  usually 
perform  tneir  functions  as  an  additional  ratner  tnan  a 
primary  duty.  Tne  automated  solution,  however,  is  equally 
useful  for  subordinate  units  of  tne  landing  force  in 
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assisting  them  in  the  effective  and  timely  management  cf 
target  information  so  that  they  may  effectively  employ  their 
supporting  arms  on  tne  most  important  targets. 

This  cnapter  has  provide!  a  review  of  tne  duties  and 
functions  of  tne  target  information  section,  tne  tools  and 
doctrinal  procedures  of  target  information  and  tne 
tecnniques  of  operation,  idditionally ,  tne  characteristics 
of  tne  target  information  function  wnich  can  be  automated 
nave  been  identified  and  analyzed.  Tne  following  cnapter 
uses  this  analysis  to  develop  a  conceptual  framewortt  for  tne 
design  of  tne  target  information  system. 
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Ill .  SYSTEM  DESIGN  CONSIDERATIONS 

A.  PRIMAP.r  CONSIDERATIONS 
1 .  SacKground 

Having  defined  tne  current  procedures  for  tee  target 
information  function,  tne  tas£  now  remains  to  provide  a 
satisfactory  system  design  for  an  automated  solution.  Tne 
design  is  influenced  by  two  important  considerations.  Tne 
nature  of  tne  lata  case  is  betn  pnysically  small  in  size  and 
functionally  restrictive  in  wnat  information  is  required 
from  it.  This,  comoined  with  a  requirement  for  a  relatively 
ligntveignt,  portable  and  versatile  computer,  manes  tne 
selection  of  a  microcomputer  an  obvious  and  logical  cnoice 
for  nardware.  Tnis  confines  tne  solution,  nowever,  to  tne 
microcomputer  environment  which,  wniie  it  nas  many  desirable 
features,  imposes  a  number  of  major  restrictions  on  tne 
design. 

The  second  major  influence  on  the  design  is  the  impact 
of  numan  engineering  on  tne  user  interface.  Tne  user  is  a 
Marine  in  the  target  information  section  of  the  FSCC  and  the 
functions  ne  performs  are  a  Known  entity.  Tne  system  must 
conform  both  to  his  level  of  training  and  computer 
sopni sti catl on  and  to  tne  functions  and  tasKs  ne  performs. 
This  requires  an  interface  whicn  is  user  friendly,  extremely 
easy  to  operate,  sufficiently  sophisticated  to  allow  tne 
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perform  toe  required  functions  effectively  and 
without  error,  and  capable  of  operating  in  a  real-time, 
interactive  mode. 

Thus,  the  solution  is  confined  by  two  separate 
environments:  tne  microcomputer  environment  and  tne  one 
defined  by  tne  friendly,  sophisticated  user  interface.  They 
Jointly  determine  tne  data  structures,  tne  control 
structures,  memory  allocation,  Interactive  complexity  and 
tne  system  modular  design.  Tne  system  must  be  designed  to 
operate  effectively  witnin  tne  restrictions  Imposed  by  tne 
microcomputer  and  tne  parameters  required  by  tne  user 
interface.  4n  abstraction  of  these  environments  is  depicted 
in  ficure  4  below. 


Figure  4.  System  Desien  Environment. 


2.  Taslcs 

k  fcey  tast  in  tne  system  design  is  tne  definition  of 
tne  usa*e  factor.  This  is  the  description  of  the  system's 
processing  requirement,  i.e.,  how  tne  lata  is  utilized  by 
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the  system.  This  leads  to  a  top-down  desien  methodology  and 
tnree  important  tasns  wnlcn  will  determine  tne  design  of  tne 
data  case  as  well  as  tne  applications  program.  Tnese  tastes 
are: 

1.  To  Identify  all  processing  functions  ana  suoaiviae 
tiiese  functions  into  modules  (processes^. 

2.  To  determine  ail  of  tne  data  tnat  eacn  process  uses  to 
perform  its  desienated  function. 

3.  To  adequately  describe  tne  system  retrieval 
requirements . 

B.  THE  USER  INTERFACE 

While  cnapter  VI  will  address  in  detail  tne  numan 
eneineerin?  aspects  of  tne  user  interface,  it  is  important 
to  recognize  at  tnis  point  in  tne  development  of  tne  system 
that  the  user  is  classified  as  a  parametric  user.  Simply 
defined,  tne  parametric  user  is  one  wnose  system  input  is  in 
tne  form  of  parameters  only.  He  is  not  a  programmer  altnou?h 
he  may  nave  programs  available  tnat  ne  can  use.  He  is 
transaction  oriented,  putting  information  into  the  system 
and  retrieving  it  from  tne  system,  generally  requiring  a 
snort  response  time.  The  parametric  user  requires  current 
and  timely  data  and  rapid  ana  easy  recovery  from  errors. 

In  addition  to  desisnin*  the  system  to  perform  tne  tastes 
and  functions  of  target  information,  it  must  oe  engineered 
for  tne  parametric  user  in  order  for  it  to  be  used 
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effectively  ani  with  a  degree  of  confidence  because  of  its 
predictable  benavior. 

In  the  design  of  an  interactive  system,  a  very  important 
consideration  is  the  appearance  of  tne  system  to  the  user. 
Use  of  the  technique  cf  interaction  by  anticipation,  that 
is,  anticipating  tne  desires  of  tne  user  and  presenting  nim 
with  a  corresponding  list  of  options,  allows  tne  user  to 
simplify  his  input  by  selecting  rather  than  specifying  the 
data.  Tne  employment  of  menu  selection  techniques  and 
computer  initiated  dialogue,  important  applications  of 
Interaction  by  anticipation,  will  be  used  to  provide  tne 
friendly  man-maenine  Interface. 

C.  USSR  DESIGN  CRITERIA 

A  particularly  important  aspect  of  tne  design  is  tie 
nature  of  the  constraints  on  the  cognitive  processes  of  the 
user.  One  constraint  is  tne  amount  of  information  tnat  a 
person  can  consider  at  one  time  and  tne  length  of  time  tnat 
tne  information  can  be  retained  in  snort  term  memorv.  Hence, 
the  information  available  from  the  system  snouid  be  simple 
enough  to  be  quickly  and  easily  assimilated. 

The  system  snouid  also  be  fast  enough  so  tnat  tne  user 
is  not  distracted  by  tne  loss  of  information  in  nis  snort 
term  memory  due  to  a  slow  response  time.  Tne  system  should 
be  able  to  reinforce  user  memory  wnenever  required.  Tnis 
implies  a  user  initiated  request  for  help  to  which  tne 
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system  must  reply  with  the  appropriate  information.  An 
important  aspect  in  designing  a  nelp  function  is  uniformity 
of  the  command  as  well  as  the  expected  reply. 

A  second  consideration  wnicn  is  important  in  tne  design 
of  interactive  systems  is  the  experience  level  of  the  user. 
The  system  snould  ee  able  to  cater  to  tne  novice  user  ar.d 
effectively  direct  his  input  to  perform  the  required  tasKs  . 
It  is  also  important  for  the  system  not  to  ignore  tne 
experienced  user.  The  interface  should  be  aDle  to  adapt  to 
tne  needs  and  characteristics  of  its  users  cased  on  tne 
user's  experience. 

The  interface  should  also  be  robust  in  nature.  It  should 
respond  ir.  an  effective  and  unambiguous  manner  to  any  input 
and  allow  the  user  to  recover  from  simple  errors.  It  snould 
discourage  illegal  input  and  guile  tne  user  to  tne  proper 
inputs  required.  It  should  provide  closure  to  the  user, 
i.e.t  a  logical  completion  to  a  specific  action  wimin  an 
expected  period  of  time.  It  should  limit  the  user  input  to 
the  necessary  data  and  instructions  sufficient  to  perform 
tne  required  tasics. 

This  is  test  accomplished  for  tne  narametric  user  ty 
interaction  by  anticipation  and  a  restricted  and  unambiguous 
flow  of  man-macnine  communications.  Thus,  communica tions 
from  the  user  to  tne  computer  is  by  discrete  selection  cf 
semantically  meaningful  options,  and  from  the  computer  to 
tne  user  by  tne  presentation  of  information  contained  in  tne 


43 


menu  selection  or  dialogue  frames.  Tnis  will  allow  for  rapid 
and  easy  operations  for  tne  user  and  a  unity  of  design  for 
tee  implementor. 

D.  THE  MICROCOMPUTER  ENVIRONMENT 

Microcomputers  impose  a  stringent  set  of  restrictions  on 
tne  resources  available  w.oen  implementing  or  executing  a 
program.  Tn.ese  restrictions  include  tne  small  size  of  main 
memory,  tne  lengtny  access  time  and  small  capacity  of 
secondary  storage  and  tne  low  processing  rate. 

Typically,  microcomputers  are  constructed  witn  32  to  64K 
bytes  of  main  memory.  When  consideration  is  made  for  tne 
operating  system,  tne  applications  program  and  tne  data 
case,  it  cecomes  oovlous  tnat  tney  cannot  ail  exist  in  main 
memory  at  tne  same  time  and  tne  partitioning  of  memory  and 
tne  arrangement  of  secondary  storage  will  ce  a  Key 
consideration  in  tne  system  design.  Putting  all  tne  data 
into  main  memory  is  not  feasicie  because  of  its  size,  yet 
putting  all  tne  data  in  secondary  storage  results  in 
unacceptable  response  time. 

System  response  time  is  important  to  tne  user.  Tnus, 
tnose  operations  to  wnicn  ne  expects  a  quiet  answer  must  be 
performed  quietly  witn  minimal  access  time.  For  otner 
operations  wfcich  are  logically  time  consuming  to  tne  user 
(for  example,  input  of  a  new  target  into  tne  target  list', 
closure  will  have  to  be  delayed  (witn  a  computer  advisory 


message)  wniie  tne  information  is  processed.  Tne  routines  of 


tne  applications  program  must  he  designed  tc  optimize  tne 
accesses  to  secondary  storage,  wnlcn  is  tne  bottleneck  in 
microcomputer  systems. 

S.  FUNCTIONS  OF  T HE  SYSTEM 

From  an  analysis  of  tr.e  information  provided  ty  tne 
target  card  file  and  tne  functions  and  duties  of  tne  target 
information  section,  a  number  of  major  functions  of  tne 
system  nave  been  identified.  From  these  functions,  syster 
output  nas  been  identified,  botn  in  tne  form  of  display  on  a 
video  terminal  and  printed  hard  copy.  Tnese  functions  and 
outputs  determine  tne  design  of  tne  lata  case,  tne 
applications  program  and  tne  overall  system. 

1 .  Primary  Functions 

Tne  primary  functions  of  tne  system  involve  tne 

manipulation  and  input  of  target  information  into  tne  proper 

storage  formats.  Tnese  functions  include: 

Add  a  target  to  tne  file 
Delete  a  target  from  tne  file 
Cnange  information  about  a  target 
Cnange  target  status  (active/inactive ) 

Copy  data  base  to  a  backup  fixe 
Initialize  tne  target  file  data  base 
Display  certain  target  information 
Print  certain  target  information 

These  last  two  functions  could  become  very  extensive 
operations  if  desired.  However,  a  carefully  restrictive 
design  of  tne  data  base  model  and  a  desire  to  limit  tne 
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semantic  options  of  me  parametric  user  to  certain, 
defined  operatloms,  nas  reduced  tnem  to  mana^aoie  yet  fuiiy 
appilcatle  functions. 

2.  Display  Options 

Tne  CRT  (catnode  ray  tube)  device  •ill  te  tne 
primary  user  interface  mechanism.  Most  of  tne  information 
input  and  extracted  from  tne  system  will  te  performed  via 
tne  CRT.  Tne  interactive  queries  to  tne  data  case  will 
result  ir.  tne  following  display  options: 

Display  a  complete  target  card 
Display  a  list  of  all  the  active  targets 
Display  a  list  of  all  tne  inactive  targets 
Display  tne  target  list 

Display  tne  information  for  tne  next  TAR2UL 
Display  a  list  of  targets  by  specific  parameter(s) 

Display  parameter  status  for  tne  active  targets 

The  parameters  indicated  above  are  selected  categories 
of  target  information  obtained  from  tne  target  card  wnic.n 
are  tne  typical  parameters  for  special  listings  and  the 
cross-index  flies.  It  represents  a  selection  of  those  items 
of  information  which  can  be  most  effectively  utilized  by  the 
?SC  and  tne  supporting  arms  representatives  in  tne  i’SCC. 
These  parameters  Include: 


Target  Priority 
Target  Classification 
Target  Number 
Target  Status 
Target  Type 

Supporting  Arm  Assigned 
Attached  Target 
Target  Information  Accuracy 
Jrid  Coordinates 

.5.  Print  Options 

Hard  copy  of  tne  target  information  is  a  definite 
requirement  for  operations  at  any  level  FSCC.  Tne  system 
will  nave  tne  capability  to  print  tne  target  list  and  tne 
list  of  targets.  The  production  of  a  TAR3UL  based  on  tne 
transactions  with  tne  data  base  sin~e  tne  last  published 
TAR3UL  will  provide  a  significant  neip  to  tne  TIO. 

The  tareet  listines  by  specific  parameter  (for  example, 
a  list  of  all  active  targets,  class  C,  priority  II,  of 
tareet  type  "SEAC"  assigned  to  artillery)  Is  a  requirement 
tnat  will  be  applicable  to  ail  members  of  tne  FSCC.  Tne 
system  will  also  nave  the  capability  to  print  a  ~opy  of  tne 
target  card  for  dissemination  to  otr.er  aeencies  as  well  as 
to  provide  a  manual  backup  in  case  of  power  or  computer 
failure. 

F.  SUMMARY 

This  chapter  alone  with  tne  preceedine  chapter  nas 
defined  tne  doctrinal  functions  of  target  information, 
determined  tne  environment  for  tne  automated  solution  of 
tnese  functions  and  presented  tne  system  requirements  for 
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tills  solution.  Tnese  cnapters  form  a  necessary  foundation 
for  tne  subsequent  cnapters  wnicn  address  tne  specific 
details  of  tne  system  and  tne  data  base  design.  Tne  nett 
cnapter  addresses  tne  actual  system  design  and  includes  tne 
nardvare  and  software  selection  and  a  top-down,  modular 
approach.  It  contains  important  iecisions  concerning  tne 
data  base  wnicn  are  developed  in  greater  detail  in  cnapter 
7. 
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IV 


SYSTEM  DESIGN 


A.  CONCEPTUAL  SYSTEM  DESIGN 

1 .  Generality  of  Approach 

In  talcing  a  top-down  classic  approacn  to  tne  desizn 
or  tne  tareet  Information  system,  tne  initial  design  does 
not  consider  tne  restrictions  imposed  by  tne  operating 
environment.  Tnis  is  done  for  two  reasons.  First,  tne 
conceptual  design  presents  a  simple,  traditional,  straignt 
forward  solution  wnicn  can,  in  concept,  ce  readily 
implemented.  Second,  it  provides  tne  basis  upon  wnicn 
modification  and  adjustment  may  be  performed  to  fit  tne 
simple  solution  into  tne  restrictive  environment.  Tne  size 
of  tne  system,  tne  interface  requirements,  ana  tne 
restrictive  data  base  view  will  cause  tne  conceptual  cesisn 
to  be  tailored  and  modified  to  operate  in  tne  selective 
environment. 

2.  Data  Base  Considerations 

Tne  target  card  data  provides  tne  entities  (or 
records),  attributes  and  relatlonsnips  of  a  aata  base 
system.  Tne  controlling  software,  tne  lata  base  management 
system  (DBMS),  would  normally  contain  language  facilities 
for  defining  tne  data  base,  for  manipulating  tne  lata  base 
information  and  for  obtaining  information  from  tne  data 
base.  Tnis  last  facility,  tne  nign  level  query  language. 


allows  trie  user  to  manage  trie  information  of  trie  data  tase 


and  perform  tne  required  operational  functions. 

Tne  data  base  concept  enaoles  tne  user  to  store  tne  data 
in  space  saving  and  efficient  ways.  Redundancy  of  data  can 
be  eliminated  and  data  items  deleted  wMcn  can  be  implicitly 
derived  from  otner  data  items.  Tne  system  allows 
construction  of  different  views  of  tne  data  so  tnat 
different  users  can  perform  different  functions  on  tne  same 
type  of  data.  Applications  programming  is  simplified  since 
it  only  needs  to  specify  parameters  to  tne  DBMS  wnicn 
locates  and  fetcnes  tne  data. 

Tnus,  tne  design  of  tne  data  Dase  portion  of  tne 
conceptual  system  will  require  tne  construction  of  tne 
logical  and  tne  pnyslcal  view  of  tne  information,  definition 
of  the  Information  in  terms  of  tne  data  base  definition  and 
manipulation  languages  and  providing  a  LBN'S  witn  a  facility 
for  query  language  translation  to  operate  on  the  data  base. 

3.  Applications  Program  Considerations 

Tne  user  environment  remains  as  defined,  a  friendly, 
sopnistlcated  interactive  man-macnine  interface.  Tne 
applications  program  must  interact  witn  tne  user  and  witn 
tne  DBMS.  Tne  use  of  a  query  language  for  tne  parametric 
user  would  require  tne  user  to  learn  tne  data  base  query 
language.  Alternatively^  collection  of  query  language 
statements  could  be  imbedded  in  tne  applications  program  and 
selected  by  tne  user  utilizing  tne  menu  selection  interface. 


These  statements  would  interact  directly  witn  the  DBMS. 
Additionally,  the  host  language  could  be  extended  to  enacle 
it  to  pass  information  to  tne  DBMS  in  tne  form  of  a 
procedure  call. 

Tne  requirement  for  menus,  neip  functions  and  system 
explanations  could  De  effectively  solved  by  tne  use  of 
user-oriented  utility  modules  which  could  be  accessed  as 
needed.  Tne  Dasic  conceptual  system  design  derived  from  a 
top-down  view  of  tne  target  information  system  taste  is 
depicted  in  figure  5.  This  basic  design  will  be  refined  to 
fit  wi tnin  tne  solution  environment . 


Figure  5.  Design  of  tne  Conceptual  Model. 

B.  PRELIMINARY  CONSIDERATIONS  FOR  SYSTEM  DESIGN 

Witn  tne  basic  framework  laid  out  by  tne  conceptual 
model,  tne  tast  now  becomes  one  of  attempting  to  insert  tnis 
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classic  approach  design  into  trie  restricted  environment  of 
tne  microcomputer.  Tr.is  reauires  a  high  degree  of 
specificitv  in  order  to  identify  tne  tools  to  be  employed  in 
tne  implementation  and  tne  methodology  of  employing1  tnose 
tools.  Tne  target  macnine  must  be  identified  to  precisely 
define  tne  microcomputer  constraints.  Tne  data  basQ  model 
and  Its  pnvsical  ana  logical  organization  must  be  defined, 
tne  applications  program  functions  and  tasK  flow  analysis 
must  be  determined  and  tne  target  programming  language  must 
be  identified. 

C.  HARDWARE  SELECTION 

Tne  selection  of  tne  system  nardware  was  driven  by  t.nree 
considerations.  First,  it  nad  to  be  a  commercially 
available,  typically  configured  microcomputer.  Sucn 
generality  is  needed  if  tne  system  was  to  be  transportable 
to  otner  microcomputers.  In  tne  searcn  for  a  typical 
microcomputer,  an  effort  was  made  to  avoid  tne  none  or 
personal  computers  wnlcn,  wniie  small,  easily  transportable 
and  Inexpensive,  possess  neither  the  processing  power  nor 
tne  virtual  memory  capacity  needed  for  tne  system. 

The  second  consideration  was  for  a  computer  that 
possessed  acceptable  size  and  weight  cnaracten st i cs  for 
transportability,  had  a  compact  configuration,  was  generally 
rugged  for  a  commercial  product  and  nai  sufficient 
processing  capacity. 


S2 


B 


1 


The  third  consideration  wa s  avaiiabil  ity.  Tne  ALTOS 
ACS -8000  is  a  representative  of  micro-systems  commercially 
available,  and  was  selected  for  use  in  tnis  worn.  Tne  ALTOS 
microcomputer  conforms  well  to  tne  desired  computer 
cnaracteristics .  LCDR  D.  L.  Smitn  in  r.is  thesis  entitled 
Method  to  Evaluate  Microcomputers  for  Non-tactical  Shipboard 
rJse  cited  the  ALTOS  as  one  of  the  top  four  mi ~rocompu ter 
systems  evaluated  and  found  it  suitable  for  use  on  U.S.  Navy 
snips. 

Tne  ALTOS  ACS-8000-1  is  a  single  board  Z-80.A  based 
microprocessor  with  54£  bytes  of  random  access  memory  and 
two  Snufrart  SA-900/901  eignt  incn,  single  side  floppy 
diskette  drives  contained  within  tne  16  by  7  by  l?  incn 
compartment.  It  requires  a  CRT  for  input/output  and  supports 
128  characters  of  upper  and  lower  case  ASCII  with  80 
characters  per  line  on  a  24  line  video  display.  Tne  computer 
weighs  approximately  35  pounds,  nas  a  forced  cooling  system, 
utilizes  standard  115  volt  electric  power  witn  a  cattery 
baclcup  and  operates  within  a  temperature  range  of  32-105 
degrees  farenneit  and  a  numidity  range  of  10-90  percent. 

The  two  floppy  diskettes  with  tne  IBM  3740  single 
density  format  ana  tne  64£  of  main  memory  gives  a  total 
memory  space  of  575K  bytes.  The  nign  level  language  support 
for  tne  ALTOS  Includes  tne  CP/!*  operating  system,  Basic, 


FORTRAN,  Pascal,  PL/I-90,  APL,  LISP,  COBOL  and  the  Micro 
Data  Base  Systems  DBMS  for  a  microcomputer. 


D.  PROGRAM* IN3  LANG'JASS  SELECTION 

The  selection  of  a  programmine  laneuase  was  influenced 
by  tnree  major  considerations.  First,  tne  nardware  selected 
and  the  availaoility  of  assemblers,  interpreters  and 
compilers  to  support  a  programming  project  on  this  nardware 
narrowed  tne  field  considerably.  Second,  tnere  was  a  desire 
to  use  a  language  wnicn  is  relatively  self-explanatory, 
self-documenting  and  transportable.  And  finally,  tne 
language  would  nave  to  support  a  robust,  user-oriented 
interactive  program. 

Of  the  available  lansuages,  Pascal  was  selected  for  a 
number  of  reasons.  It  has  features  wnicn  maire  it  readily 
useable  for  systems  and  applications  programming  in  that  it 
is  "strongly  typed",  requiring  explicit  data  declaration.  It 
forces  the  data  base  to  be  completely  designed  before  tne 
source  program  is  written. 

Pascal's  structure  encourages  modularity  as  well  as 
top-down  design  and  implementation.  It  is  a  relatively 
simple  language  and  is  tne  oasis  for  tne  proposed  Department 
of  Defense  standard  nign  order  programming  language,  Ada. 
The  most  popular  version  of  Pascal  for  microcomputer  use  is 
tne  University  of  California  at  San  Diego  (UCSD)  version 
developed  by  the  University's  Institute  for  Information 
Systems. 

The  UCSD  (Mini-Microcomputer)  Pascal  version  1.4b  is  a 
system  intended  to  run  on  a  stand-alone  mini  or 
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microcomputer.  It  is  nigniy  machine  independent  since  it 
runs  on  a  pseud o-macnlne  interpreter.  Tne  system  contains  a 
compiler,  linxer,  screen  oriented  editor  and  an  operating 
system  wnicn  are  compatible  wi  tn  Z-B4?  microprocessors  tnat 
operate  under  tne  Digital  Researcn  CP/V  operating  system. 

Because  of  tne  microcomputer  environment,  mere  are  a 
number  of  differences  between  tne  UCSD  Pascal  and  tne 
standard  version  of  Pascal  as  defined  by  Jensen  and  wirtn. 
Particularly  nelpful  are  a  number  of  string  intrinsics, 
random  access  of  files  by  a  SEEK  command,  file  nandling 
commands  and  segment  procedures.  Tne  segment  procedure 
capaoility,  for  example,  enaoles  tne  user  to  segment  tne 
applications  program  into  a  main  program  and  up  to  six 
procedure  modules  wnicn  are  retrieved  from  secondary  storage 
when  called.  Tnis  allows  a  large  portion  of  the  program 
object  code  to  reside  on  disfc  wnen  not  needed,  tnus. 
Increasing  tne  size  of  main  memory  for  computation  and 
operating  system  functions. 

E.  DATA  BASE  CONSIDERATIONS 

Tne  design  of  tne  pnyslcal  and  logical  data  base  is 
addressed  in  detail  in  tne  next  chapter  ana,  accordingly, 
tnis  section  will  address  only  tnose  items  of  importance  to 
the  system  design.  In  tnat  tne  user  view  of  tne  scnema  and 
tne  conceptual  view  of  tne  scnema  are  identical,  and  because 
there  is  no  requirement  for  an  integrated  data  base,  tne 
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traditional  lata  models  (relational,  hierarcnial  and 
networs)  will  not  be  employed. 

Consideration  was  given  to  using  existing  OEMS  systems 
for  tne  target  information  system  but  tney  were  rejected  for 
essentially  two  reasons.  First,  tne  target  information 
system  is  a  restricted,  single  application  data  base.  It  is 
sufficiently  restricted  tnat  a  general  purpose, 
multi-faceted  data  base  management  system  is  not  required. 
Second,  tne  use  of  a  DBMS  query  language  was  considered  botn 
time  consuming  and  difficult  to  learn  for  tne  system  user 
and  unnecessarily  complicated  tne  interface.  Tnis  is 
especially  true  because  tne  system  is  designed  to  limit  tne 
type  of  queries  allowed  on  tne  data  base. 

By  extending  tne  nost  language  from  tne  applications 
program  to  tne  data  base,  data  independence  is  lost. 
However,  since  tne  system  will  not  allow  tne  user  to  access 
tne  data  base  in  any  way  otner  tnan  tnat  specifically 
allowed  by  the  system  interface  design  and  since  tnere  is 
only  one  view  of  tne  data,  tnis  does  not  present  a  problem. 

Tne  data  base  will  consist  of  two  files.  Tne  first  is  a 
flat,  relational  model  representation  witn  tne  target  as  a 
single  record  and  the  target  information  pertinent  to  that 
specific  target  as  tne  attributes  of  tnat  record.  All  of  tne 
active  and  Inactive  targets  will  be  contained  in  this  main 
target  file.  Tne  second  file  will  be  tne  data  base  query 
file  consisting  of  tne  primary  and  secondary  Keys  for  each 
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target.  Tne  standard  system  queries  will  return  Information 
in  the  tareet  list  format  ana  will  ootain  all  the  necessary 


data  from  tne  data  ease  query  file. 

This  partition  of  data  case  files  increases  tne  data 
redundancy  of  tne  system  since  all  tne  data  in  tne  query 
file  is  duplicated  in  tne  main  file.  However,  this  is  done 
to  improve  tne  system  response  time  to  user  queries  dv 
greatly  reducing  tne  lisle  accesses  that  would  nave  been 
required  to  process  the  main  file.  This  tradeoff  is  maae  in 
favor  of  the  user  interface  and  at  tne  expense  of  additional 
storage  space  and  Increased  program  complexity. 

Tne  secondary  Keys  used  to  process  tne  target 
information  queries  (priority,  classification,  type,  etc.) 
are  contained  in  tne  in  tne  data  base  query  file.  An  index 
file  containing  the  addresses  of  the  tareet  records  is 
constructed  in  main  memory  at  tne  beginning  of  tne  program, 
thus,  eliminating  the  need  for  a  separate  record  address 
file  and  reducing  tne  numDer  of  disic  seelcs  required  to 
access  a  record  from  tne  main  tareet  file.  Vere  this  not 
done,  tne  system  would  nave  to  access  an  address  index  file 
in  secondary  storaee  to  obtain  the  address  and  tnen  access 
tne  record  in  tne  mam  target  file  in  secondary  storage  to 
obtain  the  record.  Having  the  index  in  main  memory  requires 
only  one  access  to  tne  nisi,  tne  access  for  tne  actual 
record . 
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The  modules  of  ttie  applications  program  directly 
Interface  to  tne  data  base  files  accessing,  manipulating  and 
rewriting  tne  data  as  necessary.  Tne  system  performs  data 
base  operations,  not  data  base  management  and  is  an 
extension  of  tne  nest  language. 

7.  USSR  INTERFACE  CONSIDERATIONS 

In  tne  preceding  cnapter,  tne  user  interface  was  defined 
and  tne  general  requirements  determined.  Tnese  reouirements 
are  now  translated  into  specific  design  parameters  for  tne 
target  information  system.  Additional  discussion  of  tne  user 
interface  and  details  of  tne  dialogue  techniques  used  are 
presented  in  deptn  in  chapter  71. 

The  user  interface  is  characterized  by  four  major 
attributes : 

1.  Ail  communications  between  tne  user  and  tne  computer  is 
through  menus,  if  a  simple  command  is  adequate,  or  through 
interactive  computer  initiated  dialogue  for  more  extensive 
data  entry. 

2.  Extensive  help  is  available  at  ail  times.  Tnis  help 
Includes  explanations  of  tne  options  available,  tne  format 
of  the  required  input  and  examples  of  tne  correct  input. 

3.  The  display  processing  time  is  as  snort  as  possible  to 
remain  within  the  constraints  of  snort  term  memory 
retention  and  logical  closure. 
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4.  Tne  user  is  restricted  to  tne  system  defined  options 
for  data  input  and  data  and  information  retrieval.  Tnus , 
only  those  procedures  defined  by  tne  system  tnrouett  tne 
menus  and  tne  dialogues  can  ce  used. 

G.  APPLICATIONS  PROGRAM  CONSIDERATIONS 

Tne  metnodology  of  applications  program  design 
encompasses  tnree  separate  but  interrelated  areas,  earn  of 
wnicn  is  continually  influenced  by  tne  system  aeslen 
environment.  Tnese  areas  are  semantic  structure  design, 
syntactic  structure  design  and  software  design. 

In  tne  top-down  semantic  design  stage,  tne  system  goals 
were  translated  into  tne  applications  program  *oais  and  tne 
system  functions  and  requirements  were  determined, 
categorized  and  prioritized.  Tne  tasic  flow  of  tne  system  was 
analyzed  and  alternatives  developed  and  compared.  Tne 
selection  of  tne  most  effective  solution  to  eacn  of  tne 
problems  posed  by  tne  system  requirements  was  expressed  as  a 
functional  module.  Tnis  module  was  tnen  furtner  brolcen  down 
into  smaller  modules  wnicn  address  particular  parts  of  tne 
functional  requirement.  Tne  data  structures  and  control 
structures  were  tnen  determined  wnicn  best  enable  tnese 
modules  to  perform  tne  required  functions. 

Tne  design  of  tne  syntactic  structures  paralleled  tnat 
of  tne  semantic  structures  and  involved  tne  determination  of 
display  formats  from  a  comparison  of  different  approacnes  to 


the  user  interface.  In  addition  to  display  formats,  system 
response  formats,  error  diagnostics,  user  aids  and  help 
facilities  were  also  specified. 

The  software  was  designed  in  a  top-down  modular  fasnlon 
and  best  use  was  made  of  tne  facilities  of  tne  tfCSD  Pascal 
system  segment  procedures  as  well  as  the  structured  approach 
provided  by  the  Pascal  language. 

Tne  target  information  system  applications  program 
consists  of  sii  major  modules.  The  primary  module  is  the 
Interface  module.  It  acts  as  tne  executive  of  tne  program 
and  controls  tne  interaction  of  tne  user  input/output,  the 
data  base  operations  and  tne  segment  procedures. 

The  remaining  modules  are  segment  procedures,  that  is, 
they  reside  in  secondary  storage  until  called  into  main 
memory  by  a  procedure  invocation.  Upon  invocation,  tney  are 
read  into  main  memory  and  computation  continues.  When 
control  is  returned  to  tne  calling  procedure  (in  this  case, 
the  Interface  module),  the  memory  space  is  deallocated.  The 
UCSD  system  allows  up  to  six  of  tnese  segment  procedures  and 
permits  them  to  be  nested  in  order  to  further  reduce  the 
amount  of  code  necessary  in  memory. 

Tne  Initialize  module  is  used  wnen  tne  data  base  system 
is  Initialized  and  a  new  target  file  is  created.  The  Query 
module  contains  tne  menus  and  tne  semantics  for  tne  system 
queries  to  the  data  base  query  file.  It  is  used  only  when 
target  information  by  specific  parameter  is  desired  by  tne 
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TIO.  A  Utility  module  contains  a  number  of  housekeeping 
routines  for  constructing  tne  TARBUL,  determining  target 
file  status,  copying  tne  data  base  to  another  diskette, 
printing  target  listings  and  otner  functions. 

Tne  Target  module  is  tne  major  segment  procedure  and  is 
used  for  adding,  deleting  and  changine  targets  in  tne  main 
target  file.  It  also  updates  tne  data  base  query  file  and  if 
necessary,  the  TARBUL  file.  The  Inform  module  contains 
user-oriented  information  concerning  doctrinal  terminology, 
systems  instructions,  version  information  and  tactical 
guidelines. 

The  target  Information  system  design  is  illustrated  in 
figure  6.  Because  mucn  of  tne  design  was  influenced  by  tne 
microcomputer  constraint,  tne  amount  of  object  code  resident 
in  memory  at  one  time  has  been  minimized.  The  illustration 
in  figure  ?  snows  tne  expected  allocation  of  secondary  ar.d 
main  memory  for  the  system,  (see  pages  64  and  65^ 

H.  SECURITY  AND  INTEGRITY 

Security  for  the  system  is  essentially 
non-dlscretionary .  Tne  system  is  secure  because  it  is 
located  in  a  secure  area  (the  FSCC  is  usually  a  restricted, 
controlled  access  area  within  a  secure  perimeter).  Tne 
targets  contained  in  the  list  of  targets  are  typically 
classified  confidential  and,  therefore,  tne  diskettes  would 
be  considered  classified  matter.  Thus,  tne  usual  precautions 
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and  practices  for  tne  security  of  classified  material  are 
sufficient  for  tne  system. 

As  a  further  safeguard  and  security  feature,  tne  system 
will  nave  a  user  password  wnicn  will  allow  only  bonafide 
individuals  to  access  tne  data  case  of  targets.  Input  or  an 
improper  or  erroneous  password  will  Keep  tne  user  in  tne 
outer  edfire  of  tne  Interface  module  and  prevent  opening  tne 
data  base  index  file  without  wnicn,  tne  data  cannot  be 
accessed.  Tne  Utility  module  nas  a  subroutine  which  allows 
tne  user  to  specify  nis  own  passwords. 

The  target  information  system  will  reside  on  an  eight 
incn  floppy  diskette  wnicn  will  contain  tne  Pascal  operating 
system  and  the  object  code  of  tne  applications  program.  Tne 
source  code,  editor  and  compiler  will  be  removed  from  tne 
diskette  to  prevent  any  user  from  modifying  or  changing  any 
part  of  tne  system.  Tne  user  can  only  cnange  tne  password 
and  the  target  information. 

Upon  activation  of  the  system,  a  user  advisory  messaee 
will  be  printed  on  the  CRT  screen  informing  tne  user  of  nis 
responsibility  to  safeguard  tne  classified  information.  All 
of  the  printed  output  of  tne  system  will  contain 
confidential  markings  on  each  paee  as  required  by  current 
security  regulations. 

Nuclear  and  chemical  target  information  and  analysis 
will  be  excluded  from  tne  target  information  system  and 
processed  in  accordance  with  current  procedures.  This  is 


done  primarily  because  tnese  targets  require  special 
techniques  for  analysis,  are  typically  of  a  higher 
classification  than  confidential  and  are  of  sucn  a  deeree  of 
sensitivity  tnat  special  handling  is  usually  required. 

I.  TRANSITION 

A  Key  element  of  tne  system  is  tne  physical  am  logical 
design  of  the  data  base.  Since  the  system  is  functionally 
restrictive,  tne  data  base  nas  been  designed  to  provide 
optimal  performance  to  the  user.  This  has  resulted  in  desien 
parameters  wnicn  are  explained  in  depth  in  tne  next  chapter. 
The  chapter  develops  some  of  the  important  considerations  of 
data  base  tecnnology  and  the  methodology  of  data  base 
selection  and  file  determination.  These  techniques  were  used 
to  design  tne  loelcal  target  information  record. 

System  and  environmental  requirements  impact 
significantly  on  tne  pnysical  data  base  design  and  a  number 
of  alternatives  are  presented  and  evaluated.  Tne  pnysical 
record  desien  as  well  as  the  inverted  file  indices  are 
described  in  detail  and  provide  a  Justification  for  tne 
system  design  presented  in  this  chapter. 
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7.  DATA  BASE  DESIGN 


A.  PRELIMIN  ART  DESIGN  PROCESS 

Before  tne  design  of  toe  pnysicai  ana  toe  logical  data 
case  can  proceed,  tnere  are  certain  ground  rules  and  design 
criteria  tnat  must  fee  established.  Data  base  technology  nas 
become  more  formalized  in  tne  past  ten  years  with  general 
acceptance  of  tnree  major  data  models,  the  relational,  the 
nierarcnial  and  tne  network  or  CODASTL.  Tne  tasic  now  becomes 
one  of  determining  the  content  of  the  target  Information 
data  base  and  whlcn  of  tne  major  data  models  is  most 
appropriate  for  the  detailed  design  of  tne  logical  and 
physical  data  base. 

1 .  Data  Base  Concepts 

Perhaps  the  initial  starting  point  should  be  a 
definition  of  tne  lata  base.  One  of  tne  most  often  quoted 
sources  is  James  Martin's  from  his  Computer  Data-base 
Organization : 

A  data  base  may  be  defined  as  a  collection  of 
interrelated  data  stored  toeether  with  as  little 
redundancy  as  possible  to  serve  one  or  more  applications 
in  an  optimal  fashion;  the  data  are  stored  so  that  they 
are  independent  of  programs  which  use  the  data." 

It  is  important  to  distinguish  between  a  data  base 
system  and  a  file  system.  A  file  system  organizes  the  data 
storage  capability  wnicn  is  provided  by  tne  hardware  or 
operating  system  software.  The  hardware  is  partitioned  into 


flies  wnich  are  associated  with  a  particular  user  or  for  a 
specific  purpose.  Operations  on  one  file  are  done  in 
isolation  from  tne  otner  files  (or  otner  users).  Tnus.  to 
access  tne  same  information  from  many  similar  files  may 
require  as  many  separate  operations  as  tnere  are  files. 

A  data  base  system,  on  tne  otner  nand,  organizes  tne 
file  storage  capability  which  is  provided  by  tne  file 
system.  Tne  relaticnsnip  between  elements  or  entitles  of  tne 
file  are  made  accessible  to  the  system.  T tie  user  trains 
access  to  all  of  tne  data  because  it  is  now  available 
through  relationships  to  other  data.  Additionally,  different 
users  can  access  tne  same  data  and  snare  it. 

Access  to  the  data  base  is  provided  by  a  data  language, 
a  set  of  operations  wnlcn  permit  access  to  the  data  that  has 
been  organized  by  a  data  model.  Data  base  management  systems 
are  generally  classified  by  tne  way  they  provide  access  to 
the  data.  A  self-contained  system  provides  all  the 
capabilities  and  required  services  by  itself,  typically, 
through  a  query  language.  Host-based  systems  carry  out  the 
retrieval  and  update  functions  only  and  deliver  tne  data  on 
request  to  programs  written  in  the  host  system  language. 
Occasslonally ,  tne  nost  language  is  extended  to  operate 
directly  with  the  data  base,  but  usually  with  a  loss  of  data 
independence . 
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Data  Base  Terminology 

Eaca  of  tfte  major  data  models  refers  to  concepts  of 


data  la  slightly  different  terminology.  For  example,  tne 
paysical  record  type  "target"  consisting  of  target  number, 
grid  location,  altitude,  priority,  classification  and 
description  is  called  an  entity  by  one  model,  a  segment  or  a 
logical  record  by  another  and  a  tuple  by  tae  tnird.  To  avoid 
confusion  and  misunderstanding,  a  set  of  terms  which  are 
partially  intuitive  in  nature  and  generally  from  tae 
relational  model  will  be  used.  These  terms,  their 
definitions  and  an  example  from  tne  target  information 
system  are  as  follows: 

Record . a  *roup  of  one  or  more  data  items  or  attributes 

which  corresponds  to  a  simple  record  or  entity  [a 
tareet] 

Attribute . tae  smallest  unit  of  data,  a  data  field  with 

a  certain  value  [target  AA0001  with  tae  "oriorlty" 
attribute  aas  value  I I I J 

Relationship . the  connector  between  individual  records 

of  the  same  type  or  eroups  of  records  of  different 
types  [tne  list  of  targets] 

Relation . the  set  of  all  records  of  a  *iven  type  l  the 

list  of  targets] 
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Decree . tne  number  of  attributes  in  a  record  [for  a 

record  with  target  number,  location,  priority, 
classification  and  description,  tbe  degree  of  the 
record  would  be  5  J 

Cardinality . tne  number  of  records  in  a  relation  [tne 

number  of  targets  in  the  system] 

Domain . tne  set  of  all  possible  values  for  an  attribute 

[priority  has  domain  I,  II,  111,17] 

Primary  gey . one  or  more  attributes  of  a  record  vnose 

value  uniquely  identifies  the  record  [target  number 
AA004S] 

Secondary  gey . an  attribute  which  may  or  may  not 

uniquely  identify  the  record  but  wnicn  defines  a  set 
on  tne  record  [all  priority  I  targets] 

Schema . the  structure  of  the  entire  data  base 

Subscnema . that  portion  of  tne  schema  viewed  by  a 

particular  user  or  group  of  users 

Flat  file . a  relation  in  normal  form:  a  single  level 

record  array  with  only  one  record  type 

3.  File  Determination 

Tne  total  volume  of  data  in  tne  target  information 
system  must  be  viewed  with  the  objective  of  splitting  it 
into  smaller  units  tnat  may  oe  considered  tne  basis  for 
organizing  the  data  base  file.  Having  already  determined  the 
system  functions  from  chapters  III  and  17,  tne  data  objects 


69 


and  the  relationships  to  perform  these  functions  must  be 
determined  and  organized.  Tne  results  of  tnis  organization 
will  become  tne  criteria  for  tne  modular  design  of  tne 
applications  program. 

William  House  in  Data  Base  Management  provides  an 
excellent  methodology  for  file  determination.  Data  splitting 
separates  tne  system  information  into  subsets  vnlcn  can  be 
dealt  wltn  more  or  less  independently  and  pernaps  made  an 
independent  file  of  the  data  base.  Record  design  determines 
tne  format  of  tne  content  to  appear  in  eacn  record  and  tne 
modes  of  indexing  in  order  to  establish  tne  index  data  that 
must  be  present. 

Volume  analysis  estimates  the  size  of  the  individual 
record  and  tne  size  of  tne  record's  relation  (cardinality). 
The  physical  distribution  of  tne  number  of  records  in  each 
file  must  also  be  taken  into  account  to  determine  tne  space 
management  requirements.  Activity  analysis  determires  the 
frequency  of  reference  and  estimates  tne  total  activity  for 
the  records  of  eacn  file.  It  is  tnis  analysis  that  is 
essential  to  tne  question  of  file  design  and  one  of  tne  key 
considerations  in  tne  microcomputer  environment, 
particularly  tne  access  bottleneck  to  secondary  storage. 

File  design  is  dependent  upon  the  record  structure, 
pnysicai  distribution  of  tne  records  in  tne  storage  device 
and  tne  indexing  method  employed  in  referencing  tne  record. 
Tne  critical  issue  for  file  design  is  its  performance. 


4.  File  Performance 

There  are  a  number  of  criteria  vhlcn  must  ee 
considered  wnen  estimating  the  performance  of  tne  file 
design.  There  will  inevitably  be  a  trade  off  between  storage 
space  and  processing  speed.  There  are  instances  wnen  tne 
rapidity  of  access  to  information  In  the  data  base  Is  more 
Important  than  saving  or  optimally  utilizing  tne  secondary 
storage  space.  This  may  mean  redundancy  of  data. 

Glo  Vledernold  In  Database  Design  outlines  seven 
measures  of  file  performance.  These  parameters  were 
considered  wnen  designing  tne  physical  data  base.  Tnese 
measures  of  file  performance  Include: 

1.  Storage  required  for  a  record 

2.  Time  to  fetch  an  arbitrary  record  from  tne  file 

3.  Time  to  eet  the  next  record  within  the  file 

4.  Time  to  update  by  inserting  a  record  into  tne  file 

5.  Time  to  update  by  changing  a  record  in  the  file 

6.  Time  for  exhaustive  reading  of  the  file 

7.  Time  for  reorganization  of  tne  file 

5.  Architectural  Perspective 

The  data  base  system  architecture  is  also  an 
Important  consideration.  It  depicts  tne  natural,  conceptual 
and  physical  views  of  tne  data  in  tne  data  base.  It  is  tne 
fcey  to  data  Independence  and  gives  the  DBMS  much  of  its 
power  and  flexibility. 

At  tne  most  abstract  level,  there  is  tne  external  data 
base.  This  is  the  way  in  which  the  user  views  the  data  base. 
It  consists  of  any  number  of  different  perspectives  of 
individual  users,  which  are  considered  subschemas  of  the 
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data  base.  Typically,  tne  sucscnemas  are  more  important  tnan 
an  overall  vie*  of  tne  external  lata  since  tney  define  tne 
Information  environment  for  a  single  user  or  specific 
application. 

The  external  data  base  maps  into  tne  conceptual  data 
base  which  is  the  logical  view  of  the  information  contained 
in  tne  data  base.  It  is  tne  schema,  or  combination  of  all 
the  subschema  expressed  in  the  logical  format  of  a  lata 
model.  It  consists  of  tne  records,  relations  and 
relationships  of  the  data  as  well  as  the  primary  and 
secondary  lceys  used  for  processing  tne  data  base. 

The  conceptual  level  maps  into  tne  internal  data  base, 
whicn,  as  tne  pnysical  view  of  tne  data,  is  tne  least 
abstract  level  of  the  architecture.  The  physical  lata  base 
contains  tne  records,  files,  indices,  inverted  flies  and 
record  sequences  of  the  data  base.  An  illustration  of  tne 
different  levels  of  tne  data  base  system  architecture  is 
shown  in  figure  9. 
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Figure  9.  Data  Base  System  Arcnitecture . 


6.  Types  of  Systems 

Tne  discussion  so  far  nas  mainly  considered  tne  data 
base  management  system  concepts  for  tne  target  information 
system.  Given  tne  nature  of  tne  target  information  file  and 
tne  system  environment,  otner  types  of  systems  near 
consideration.  An  appropriate  alternative  to  a  general 
purpose  DBMS  mi«rnt  be  a  sinele  application  system. 

A  single  application  data  base  system  establlsnes  an 
operation  usin*  tne  available  file  system  facilities  and 
designs  applications  programs  vnlcn  interface  to  tne  data 
base.  A  system  for  tne  routine  processing  of  data  and  tne 
answering  of  a  prespecified  and  limited  class  of  Queries  is 
sometimes  referred  to  as  an  operations  system.  This  type  of 
system  is  designated  for  a  precisely  defined  and  limited  set 
of  operations. 
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In  a  data  Case  management  system  (DBMS),  an  information 
system,  tae  nature  of  tne  queries  will  not  be  pre-defined  by 
the  system  and  lengthy  searches  may  be  necessary  when  a 
query  Is  male.  Tae  capability  to  process  generally  stated 
aueries  Is  characteristic  of  the  multi-purpose  design  of  the 
DBMS  and  often  accounts  for  its  relatively  large  size  and 

cost.  In  an  operations  system,  lensrtny  searches  can 

% 

generally  be  avoided  because  the  information  is  typically 
stored  in  the  form  it  is  needed.  The  two  types  of  systems 
use  data  bases  wnlcn  are  differently  structured  both 
logically  and  physically. 

B.  LOGICAL  DATA  BASE  DESIGN 
1 .  Data  Splitting 

Given  the  total  information  in  the  target 
information  system,  or  more  precisely,  the  set  of  data  that 
represents  this  information,  it  is  necessary  to  separate  it 
into  subsets  which  can  be  dealt  with  more  or  less 
independently. 

Tne  information  for  tne  system  comes  from  tne  target 
card.  All  of  the  information  pertinent  to  the  data  base  is 
on  tnat  card  or  can  be  implied  from  it.  A  blocs  record  of 
all  of  this  lata  pertinent  to  the  system  can  be  visualized 
in  fleure  9. 
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REMARKS 
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STATUS 

DAMAGE  REPORTED 

DAMAGE  ASSESSED 

SOURCE 

Figure  9.  Target  Information  Conceptual  Record. 


The  data  can  logically  be  split  into  different  segments, 
for  example,  description  information,  surveillance 
information,  status  information  and  source  information,  but 
a  consideration  of  the  user  and  tne  conceptual  view  of  tne 
system  is  necessary  first. 

Tnere  is  only  one  user,  tne  target  information  officer 
and  he  has  only  one  view  of  the  data,  tnat  cf  tne  target 
card.  He  may  use  that  data  differently  depending  upon  tne 
tactical  situation  or  internal  operating  procedures  but  nis 
logical  view  of  it  nas  not  cnanged.  An  integrated  data  Dase 
will  have  many  users  and  many  different  views  of  the  lata 
(one  schema  with  many  subschema).  The  target  information 
data  base  is  not  an  integrated  data  base  and  it  has  only  one 
user  and  one  view  of  the  data,  thus,  the  schema  and  the 
subscnema  are  tne  same.  Tne  need  for  data  independence 
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(logical  data  la  tills  case)  is  no  longer  required  lor  tne 
system  because  tne  external  view  is  equal  to  tne  conceptual 
view. 

Splitting  tne  target  data  does  not  achieve  any  aided 
flexibility,  simplicity,  independence  or  efficiency.  Thus, 
tbe  target  record  can  consist  of  tne  above  24  attributes,  no 
other  relationships  and  be  organized  as  a  flat  file. 

2.  Record  Design 

For  tnls  large  set  of  data  on  target  information,  a 
determination  must  be  made  of  the  format  of  the  record  and 
tne  modes  of  indexing  in  order  to  establish  tne  index  data 
that  must  be  present.  Two  alternatives  were  considered,  one 
with  a  flat  file  and  a  second  with  multiple  records.  Tne 
multiple  record  version  merely  added  more  complexity  and 
more  data  to  the  files  with  little  benefit  to  the  system 
otner  tnan  it  "loosed "  more  lite  a  data  base. 

The  flat  file  appeared  to  be  tne  simplest  conceptually 
and  tne  easiest  to  implement.  Tne  data  witnin  tne  record  was 
ordered  in  a  functional  manner  for  semantic  purposes  and  tne 
primary  and  secondary  Keys  were  determined, 

Tnere  is  only  one  way  to  uniquely  identify  a  target  and 
mat  is  by  tne  target  number.  This  is  primarily  dictated  by 
doctrinal  procedures  since  the  target  alpna/numeric 
combination  determines  the  originating  unit  as  well  as  a 
specific  target.  Target  grid  coordinates  may  be  considered 
as  an  additional  unique  Key,  however,  a  single  map  location 
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can  be  targeted  for  multiple  purposes.  Therefore,  tne  target 
number  was  selectel  as  tne  primary  icey  for  tne  record. 

Tnere  are  a  number  of  secondary  Keys  for  eacn  target  nut 
only  a  few  of  these  nave  a  real  meaning  to  tne  TIO.  Those 
Keys  wnicn  will  be  needed  to  access  certain  types  of  target 
information  nave  been  selected  as  secondary  Keys.  It  is  for 
these  Keys  tnat  tne  queries  to  tne  data  base  will  de 
designed.  Figure  10  illustrates  the  primary  and  secondary 
Keys  of  tne  target  record. 


Figure  10.  Primary  and  Secondary  Keys. 

3.  Volume  and  Activity  Anal  s. 

m  *■  l  I  »  man  — MB  — '  •  III  Mil  f 

Estimates  must  be  r.»^-e  of  individual  record  sizes 
and  tnen  of  tne  expected  file  sizes  as  well  as  determining 
the  frequency  of  reference  of  information  in  tne  data  bass. 
In  determining  record  size,  a  number  of  considerations  came 
Into  play.  Data  items  wnicn  could  be  derived  or  implied  from 
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other  data  items  were  deleted.  For  example,  if  a  target  had 
a  BDA  in  tne  record,  it  aad  been  attached  by  supporting 
arms.  If  mere  were  no  BDA,  the  target  had  not  been 
attached. 

Additional  attributes  were  identified  wnose  requirements 
were  implied  by  otner  data  items.  For  example,  target  type 
was  made  a  record  attribute  (and  a  secondary  icey)  since  the 
target  description,  being  text,  would  nave  to  be 
semantically  analyzed  in  order  to  reveal  all  targets  of 
enemy  "artillery”. 

Attempts  were  made  to  reduce  tne  size  of  stored  data  cy 
encoding  tne  domains  of  attributes.  The  domain  for  target 
priority  is  [I,  II,  III,  I V J  .  To  place  priority  III  in  tne 
target  record  file  would  tafce  three  characters;  reduced  to  a 
numerical  representation,  it  taires  only  one  number  (3). 
Target  damage  is  described  by  a  maximum  of  eight  different 
words,  the  largest  of  which  is  11  characters.  This  has  been 
reduced  to  a  single  number  from  one  to  eight. 

A  data  dictionary  was  developed  wnicn  listed  each 
attribute,  its  domain,  data  item  size  ana  data  type  (see 
appendix  A).  From  this  document,  the  size  of  tne  record  was 
determined  to  be  approximately  240  bytes.  Since  adequate 
secondary  storage  appeared  to  be  available,  a  fixed  lengtn 
record  was  selected.  In  addition,  since  more  tnan  one  3DA 
was  expected  for  a  given  target,  tne  record  size  was 
increased  to  three  BDA  per  target  bringing  the  record  size 
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to  approximately  370  bytes.  With  a  maximum  of  300  targets  in 
tne  system,  tne  file  would  occupy  appproximately  1105  bytes 
of  secondary  storage. 

An  estimate  was  made  of  tne  number  and  type  of 
references  to  tne  data  based  on  fcnown  ana  anticipated 
tactical  requirements.  Again,  tfte  design  restrictions  on 
what  tne  user  could  ass  of  tne  data  Dase  played  an  important 
consideration.  T&e  majority  of  tne  information  for  retrieval 
was  either  an  Individual  target  card  or  a  list  of  specific 
targets.  Return  of  the  target  card  to  the  user  was  a  simple 
matter  for  file  design,  merely  retrieve  tne  record  from  tne 
data  base  and  display  all  of  tne  information.  The  retrieval 
of  specific  information  is  more  complicated. 

The  specific  information  about  targets  is  best  displayed 
as  a  target  list  since  tnat  is  tne  most  useful  format  for 
the  user.  Figure  11  is  an  example  of  the  format  required 
from  tne  data  base. 
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LIST  OF  TARGETS 


TGT  NO 

CL 

PR  I 

LOCATION 

ALT 

SA 

DESCRIPTION 

AA0021* 

C 

II 

34566543 

90 

AIR 

2  T-62  TANKS 

AA0020 

C 

17 

23455565 

40 

NGF 

5  INCH  COASTAL  GUN 

AA0056* 

E 

IV 

67665466 

50 

NONE 

4  SCHOOL  BUILDINGS 

AA0013* 

A 

III 

55677412 

15 

NGF 

BUNKERED  TRENCHLINE 

AZ1022 

D 

II 

768B5454 

110 

ART! 

BN  ASSEMBLY  AREA 

AZ1005* 

C 

I 

34345656 

20 

ARTY 

PLT  ZSU  23-4 

AA0012 

B 

III 

56445456 

10 

NGF 

CONCRETE  BUNKER 

NOTE:  9  Indicates  target  list 


Figure  11.  Example  of  a  Target  List. 


4.  Design  Conclusions 

Because  tne  data  base  is  a  single  application  data 
base  and  Is  an  operations  system  rattier  tnan  an  Information 
system,  tne  use  of  a  specific  data  model  was  rejected.  Tne 
flat  file  format  lends  itself  to  tne  relational  model  and 
tne  resultant  system  approximates  tne  relational 
metnodology.  Tne  system  does  qualify  as  a  data  base. 
However,  it  is  a  very  restricted  one  due  to  its  specific 
purpose. 

Access  to  tne  data  base,  given  tne  limited  ''hoice 
imposed  upon  tne  user  by  tne  system  design,  was  by  extending 
tne  nost  language  ratner  tnan  tne  use  of  a  query  language  or 
imbedded  data  language.  Tne  record  design  incorporates  tne 
target  information  as  one  record  with  one  primary  and  seven 
secondary  Keys  for  a  total  of  22  attributes.  Tnis  monoiitnic 
record  is  depicted  in  figure  12. 
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Figure  12.  Logical  Record  Design. 


C.  PHYSICAL  DATA  EASE  DESIGN 
1 .  Svstem  Output 

Toe  system  output  must  be  considered  before 
discussine  tne  pnysical  data  base  design.  TRese  end-products 
require  a  certain  content,  format  and  response  time. 
Retrieval  of  information  for  tne  TIO  must  be  rapid  and  the 
pnysical  design  of  tne  data  must  facilitate  speed,  even  at 
tne  cost  of  storage  efficiency. 
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These  items  of  system  output  nave  previously  been 
identified  and  are  aepicted  schemati caliy  in  figure  12: 


Fieure  12.  System  Output. 


2.  Index  File  Design 

The  cnoice  of  file  organization  is  dependent  upon 
tfie  record  structure,  tne  physical  distribution  of  tr.e 
records  in  tne  storage  device  and  tne  indexing  method 
employed  to  reference  tne  record.  To  some  decree,  tne  amount 
of  storage  space  available  will  influence  tne  file  design  as 
well.  The  critical  issue  is.  however,  the  efficiency  of  its 
performance. 

The  record  is  accessed  by  its  primary  Key.  Tne  target 
number,  unfortunately.  Is  not  always  assigned  in  sequence. 
Thus,  there  is  no  logical  order  inherent  in  the  target 
number  altnougn  they  could  be  ordered  in  numerical  sequence 
for  the  sate  of  order.  But  there  is  no  consistent  order  to 
warrant  tne  use  of  sequential,  indexed  sequential,  nasned  or 
binary  tree  storage  schemes.  The  use  of  the  dense  index 
allows  us  to  access  tne  required  target  efficiently  (witn 
only  300  targets)  as  well  as  insert  new  targets  easily  at 


the  end  of  tne  file.  Wnile  deletion  of  targets  would  leave 


noles  in  tne  storage  file,  an  unusea  target  space  record 
could  be  maintained  wnicn  would  Keep  tract  of  the  noles  and 
assign  newly  inserted  records  in  tne  available  space. 

Tne  dense  index  would  nave  to  be  made  on  both  tne  tareet 
number  and  tne  grid  coordinates,  since  it  is  a  doctrinal 
requirement  to  be  able  to  sort  on  both.  Tne  UCSP  Pascal 
implementation  mates  tnis  a  mucn  easier  operation  witn  its 
string  intrinsics  and  random  access  capability  of  relative 
records.  This  also  allows  tne  index  to  be  stored  as  a 
subscripted  array  and  enables  tne  system  software  features 
to  do  most  of  tne  manipulation.  The  index  design  is 
illustrated  in  figure  14.  It  is  essentially  two  arrays  earn 
consisting  of  tne  target  number  or  tne  grid  location  for 
eacn  of  tne  allowable  330  targets. 


Figure  14 


Target  File  Index  Design. 


Tne  ease  of  tne  UCSD  Pascal  random  access  capability  is 
illustrated  in  figure  16.  Tne  SEEK  command  on  tne  file  name 
and  tne  record  number  provide  for  a  base  address  and  an 
offset  to  tne  required  target  number.  Tms  allows  for  qulcic 
and  easy  access  to  any  target  requested  by  tne  user. 


Figure  15.  UCSD  Pascal  Random  Access  Capability. 
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3.  Physical  Design  Alternatives 

Tne  file  design  will  permit  easy  and  efficient 
access  to  tne  target  record.  The  display  of  tne  target  card 
is  essentially  solved  by  tnis  design.  Vnat  remains  is  tne 
accessing  of  tne  important  attributes  for  tne  target 
listings  by  specific  parameter,  i.e.,  tne  queries  from  tne 
TIO. 

Tne  most  straight-forward  approach  is  to  access  all  of 
tne  required  data  from  tne  target  file.  An  efficient  metnod 
of  doing  this  would  be  to  use  mul ti-ii nked  lists  tnrougn  tne 
appropriate  data  items.  Header  records  would  provide  a 
pointer  into  tne  file  and  links  would  provide  access  to  each 
item  of  specific  data.  There  are  overnead  considerations  in 
tnis  approach,  particularly  in  rearranging  tne  links  when 
adding  or  deleting  a  target. 

A  major  disadvantage  to  tnis  approach  is  tne  estimated 
time  it  would  talce  to  process  a  query.  If  all  priority  I 
targets  are  to  be  retrieved,  tne  program  module  must  find 
tne  header  index  and  follow  the  pointer  tnrough  tne  target 
file  until  it  found  eacn  of  tne  priority  I  targets. 

The  disk  accessing  to  secondary  storage  is  a  bottleneck 
in  a  microcomputer  and  snould  be  minimized  whenever 
possible.  The  access  time  to  find  all  priority  I,  class  C, 
previously  attacked,  tank  targets  could  be  quite  lengtny. 
Arranging  tne  file  into  blocks  of  five  to  ten  target  records 
per  block  would  decrease  the  amount  of  disk  accesses. 
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A  second  approacn  would  be  to  use  an  inverted  file 
structure  (often  used  in  data  base  systems  to  improve  direct 
access  to  certain  data)  for  each  of  tne  secondary  Keys  with 
a  pointer  (actual  or  symbolic)  to  eacn  of  tne  specific 
records.  An  access  to  the  entire  inverted  file  index  would 
identify  by  name  or  by  location,  eacn  of  tne  applicable 
records.  Once  determined,  tne  records  could  be  retrieved. 

To  process  a  target  list  with  multiple  parameters,  only 
the  target  numbers  from  tne  indices  need  to  De  read  into 
memory  and  tne  appropriate  intersection  made  of  tne  common 
record  attributes.  This  would  entail  one  seeK  per  index  ar.d 
then  one  sees  for  eacn  appropriate  record.  Additional 
efficiency  is  obtained  if  all  tne  index  files  are  reac  into 
main  memory  wnen  tne  user  is  going  to  maKe  accesses  to  tne 
data  base.  This  will  reduce  the  number  of  dlsK  seeKs 
required  to  access  records  and  is  particularly  effective  for 
multi-parameter  queries. 

There  is  a  bit  more  efficiency  in  the  second  method, 
particularly  in  accessing  data  witn  multiple  parameters  but 
the  cost  is  in  use  of  more  secondary  storage  for  the 
inverted  files.  Witn  tne  amount  of  secondary  storage 
available  (see  tne  estimate  in  fieue  7),  tne  trade-off 
between  storage  space  and  processing  speed  is  considered 
acceptable. 

A  third  alternative  is  even  more  expensive  in  terms  of 
secondary  storage  since  it  calls  for  redundancy  of  target 
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data.  A.  subset  of  tne  (rain  target  file  can  be  formed  to 
provide  tae  data  in  a  more  accessible  form.  Tae  file  would 
be  a  separate  record  extracted  from  tae  main  target  file  and 
consist  of  only  tnose  attrlDutes  or  items  wnich  will  be 
needed  for  tae  target  auery  and  tae  resulting  output 
listing.  Tais  would  eliminate  tae  need  to  access  tae  main 
target  file  for  queries  since  an  tae  system  queries  would 
be  confined  to  tae  data  base  query  file.  Once  tae  target 
number  was  identified  by  tne  query  mecnanism,  tne 
appropriate  target  listing  information  would  be  '  obtained 
from  the  file  and  displayed  on  tne  CHT  screen. 

This  data  base  query  file  would  nave  records  of  45  bytes 
in  length  witn  a  maximum  file  size  (for  300  targets'!  of 
about  145  bytes.  The  logical  record  is  illustrated  in  figure 
16.  To  access  the  data  in  this  file,  tne  inverted  index 
files  could  be  used. 


Figure  16.  Data  Base  Query  File  Logical  Design. 

Tne  data  base  query  file  would  be  loaded  into  main 
memory  eacn  time  tne  Query  module  is  activated.  Tnere  is  no 
requirement  tcw>write  tne  file  to  secondary  storage  wnen  tne 
Query  module  is  deactivated  since  tnere  will  be  no  changes 
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male  to  the  file.  In  that  tne  Query  module  am  tne  lata  tase 
query  file  would  be  simultaneously  located  in  main  memory, 
queries  could  ce  quietly  and  efficiently  processed. 

Tnis  eliminates  tne  need  to  access  tne  dist  to  perform 
queries,  tnerefore  greatly  reducing  tne  processing-  time.  Tne 
cost,  however,  is  in  an  additional  file  in  secondary 
storage,  an  array  to  noil  tne  data  base  query  file  in  main 
memory,  redundancy  of  data  and  tailoring  of  tne  data  case 
auery  file  and  tne  Query  module  to  fit  into  main  memory 
simultaneously.  There  is  also  tne  added  complexity  to  tne 
program  when  additions,  deletions  and  changes  are  made  to 
tne  main  file  in  tnat  tnese  cnanges  must  also  be  reflected 
in  tne  data  base  query  file. 

Consideration  was  given  to  doing  all  updates  to  tne  data 
base  query  file  wniie  it  was  located  in  main  memory  since 
the  array  which  nolds  the  records  is  a  static  data 
structure.  While  it  would  improve  system  efficiency  and 
preclude  loading  tne  data  base  query  file  each  time  tne 
module  was  called,  tne  cnances  of  loss  of  data  tnrougn  a 
power  surge  or  a  system  failure  are  sufficiently  great  to 
eliminate  tnis  approacn.  Tne  differences  between  tne  two 
data  files  after  a  long  period  of  uninterrupted  operation 
would  render  tne  query  capabilities  invalid’  because  of 
inconsistent  data.  The  expected  configuration  of  the 
allocation  of  main  memory  during  data  base  query  operatiors 
is  snown  in  figure  17. 
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Figure  17.  Main  Memory  Map  For  Data  Base  Cueries 


While  each  of  tne  above  alternatives  supports  the 
logical  design  of  the  data  base,  the  third  alternative  is 
tne  fastest  and  was  selected  because  of  tne  user's  need  for 
timely  access  to  the  data  base  information.  Tne  expensive 
trade-off  in  added  complexity  and  redundancy  is  made  in 
favor  of  tne  user. 

4.  Inverted  File  Design  Considerations 

An  inversion  on  tne  secondary  keys  would  allow  the 
system  to  conduct  multiple-key  processing  of  queries.  Each 
of  tne  secondary  keys  would  nave  a  separate  inverted  file 
for  each  of  the  values  of  their  domain.  Tne  index  would 
contain  tne  actual  pointer  to  tne  appropriate  record  in  tne 
data  base  query  file.  An  example  of  an  inverted  file  for  the 
target  priority  attribute  is  shown  in  figure  18. 
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Target  Priority  Index 


Figure  19.  Example  of  an  Inverted  File  Logical  Structure. 

The  implementation  of  tne  inverted  files  couia  employ  a 
United  list  of  tne  target  location  pointers  oy  specific 
domain  of  tbe  attribute.  However,  tills  file  must  be  updated 
eac.o  time  tne  user  adds  or  deletes  a  target  from  tne  system 
as  well  as  mates  a  specific  change  wnicn  will  affect  tile 
index.  For  example,  a  priority  I  target  could  be  changed  to 
a  priority  17  target  after  successful  attacic  by  supporting 
arms.  Tnis  would  necessitate  a  cnange  in  tne  main  target 
file,  tne  data  base  query  file  and  tne  inverted  index  for 
tareet  priority  (botn  for  priority  I  and  I'M  as  well  as  an 
input  for  tne  transaction  log  of  tne  TARBUL. 

Tnis  disadvantage  combined  with  tne  complexity  of 
implementing  linked  lists,  maintaining  multiple  inverted 
index  files  and  tfte  overhead  involved  detracts  significantly 
from  tne  elegance  of  using  inverted  files.  A  simple, 
practical  and  straight-forward  solution  is  required. 
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6.  Flat  File  Array  Processing 

The  data  base  query  file  is  implemented  as  a  single 
dinension  array  of  records  so  tnat  it  can  be  loaded  into 
main  memory.  The  UCSD  Fascal  system  performs  effective  array 
processing  and  tnis  feature  can  be  used  to  perform  tne  data 
base  query  functions.  Tne  metnod  selected  for  the  target 

T ■ 

information  system  is  array  processing  of  tne  flat  fixe. 

Tne  Query  module  prompts  tne  user  to  select  tne  special 
criteria  for  tne  target  listing.  It  does  tnis  by  presenting 
tne  user  a  series  of  menus  from  which  the  secondary  Keys  and 
tneir  respective  domain  attributes  can  be  selected.  Once  tne 
attribute  is  selected,  the  module  processes  the  array  to 
determine  if  tne  targets  in  tne  array  possess  tnis 
attribute.  Sacn  target  with  tne  attribute  is  flagged  and  tne 
system  returns  to  tne  menus  for  furtner  Key  selection.  A 
domain  can  be  selected  only  once  per  list.  Tnus,  tne  system 
permits  only  tne  logical  ’’anDING”  of  one  attribute  of  tne 
domains  of  tne  secondary  Keys. 

Upon  selection  of  another  attribute,  the  system  will 
process  only  tne  targets  which  were  flagged  oy  tne  previous 
array  processing.  This  will  significantly  reduce  the  search 
time  and  result  in  increasingly  greater  refinement  of  tne 
list  for  each  subsequent  part  of  the  query.  Since  there  are 
only  six  secondary  Keys,  tne  maximum  query  size  is  six  items 
although  tne  user  could  stop  snort  of  tnat  number  at  any 
time  in  tne  processing,  tfnen  tne  user  stops  tne  query  and 
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requests  tne  listing,  tnose  targets  which  are  flagged  are 
accessed  and  written  to  tne  console  screen.  Wnen  tne  next 
query  is  initiated,  all  tne  flags  are  reset. 

Two  additional  design  features  nave  been  incorporated  to 
speed  tne  array  processing.  Tne  first  feature  is  tne  storage 
characteristics  of  tne  secondary  Keys  in  tne  record.  5acn  is 
stored  as  a  single  character  requiring  no  type  conversion 
tnus,  enabling  quiet  ana  easy  comparisons.  The  second 
feature  is  in  tne  design  of  tne  query  menus. 

The  menus  nave  been  arranged  sc  tnat  tne  most 
discriminating  Indices  are  presented  to  tne  user  first. 
Target  type  nas  a  domain  of  nine  values  and  is  presented 
first  to  tne  user.  Tnus,  tne  first  pass  at  tne  target  list 
will  probably  result  in  tne  smallest  list  of  flagged 
targets.  This  reduces  the  amount  of  array  processing  for  the 
remaining  portions  of  tne  querv.  For  example,  if  tne  system 
nas  100  targets  and  92  of  tnese  are  "active''  status  and  14 
are  of  type  "tans",  tnen  the  first  pass  in  either  case  will 
be  for  all  100  targets.  If  status  was  the  first  part  of  the 
query  tnen  tne  next  search  would  be  through  82  "active” 
targets  until  the  "tantc"  targets  were  found.  However,  if 
type  was  tne  first  part  of  tne  query,  only  14  records  of 
type  "tans"  would  have  to  be  searched  to  find  the  "active" 
targets.  Tne  first  searen  processed  192  targets,  tne  second, 
using  tne  least-list  principle,  processed  only  114  targets. 


The  physical  design  of  tne  lata  base  query  file  is  sno*n 
in  figure  19. 

QUERY  ITEI^S  TEXT 


F....Flag  P. ..  .Priority 

T....Type  A ... .Accuracy 

C... .Class  S... .Status 

SA. . .Supporting  Arm 

Figure  19.  Data  Base  Query  File  Pnysical  Design. 

5.  Data  Base  Partitioning 

In  addition  to  the  main  target  file  and  the  data 
base  auery  file  addressed  above,  the  functions  of  the  system 
require  additional  file  considerations.  In  particular,  tnere 
is  the  requirement  to  produce  a  TARBUL  «me n  requested  by  the 
TI3.  Tne  system  must  retain  in  a  separate  file,  an  tne 
information  that  is  appropriate  for  the  TARBUL.  Typically, 
this  information  consists  of  targets  added  to  or  deleted 
from  the  tareet  list,  cnanees  to  targets  on  the  tareet  list 
and  significant  BDA  on  attached  targets.  Tne  Target  module 
of  tne  applications  program  extracts  and  formats  the 
appropriate  information  for  tne  TARBUL  file  in  conjunction 
with  normal  processing. 


A  security  feature  of  tne  system  is  a  user  defined 
password  wnicn  allows  entry  into  tne  program  only  wnen  tne 
proper  password  nas  been  received.  In  order  to  provide  for 
tne  retention  of  passwords  between  uses  of  tne  system,  a 
small  file  was  constructed  wnicn  contained  tne  user 
password.  A  procedure  of  tne  system  allows  tnis  password  to 
be  written  to  tne  diskette  and  retrieved  wnen  tne  system  is 
activated. 

Tnere  is  a  requirement  to  provide  tne  user  witn  a  file 
status  report  on  a  periodic  basis.  It  is  essentially  a 
statistical  breakdown  giving  tne  numDer  of  active  targets, 
inactive  targets  and  targets  on  tne  target  list  as  wen  as  a 
count  of  tne  targets  in  eacn  attribute  by  domain.  A  separate 
file  could  be  kept  for  tnis  information,  but  to  decrease 
complexity  and  storage  requirements  for  tne  system,  a 
routine  from  tne  Utility  module  is  used  to  accumulate 
statistics  from  tne  data  base  query  file  and  display  tne 
information  to  tne  CRT  screen  wnen  reauestei  Dy  tne  user. 
Once  again,  naving  tne  data  base  query  file  in  main  memory 
will  reduce  tne  '•omputation  time  needed  for  tnis  process. 

Tne  data  base  is,  tr.us,  partitioned  into  two  aata  base 
riles  (one  a  suoset  of  tne  otner)  and  two  utility  files,  tne 
TARBUL  file  and  tne  password  file.  Tney  must  snare  secondary 
storage  space  witn  routines  of  tne  operating  system  and  tne 
applications  program  object  code.  Tne  partitioning  of  tne 
data  base  is  depicted  in  figure  HU. 
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Figure  22.  Data  Base  Partitioning. 


D.  OTHER  CONSIDERATIONS 

In  considering  inverted  flies,  it  was  determined  that 
some  record  attributes  did  not  yield  a  sufficiently 
discriminating  index.  For  example,  tne  data  item  "status" 
yielded  a  poor  index  since  only  two  values  are  possicie, 
active  and  inactive.  In  an  effort  to  establish  more 
discriminatory  indices  and  at  tne  same  time  reduce  tne 
pnyslcal  size  of  tne  data  items  in  a  record,  index  items 
were  combined  and  compressed  in  a  coded  form.  Target  status 
was  enlarged  to  encompass  tne  target  list  index  and  tne 
target  attacKed  index.  Tne  combining  of  tr.ese  three  indices, 
eacn  wi tn  domai ns  of  value  two ,  yields  one  inc ex  with  a 
valid  domain  of  six  values.  Tne  newly  formed  index  is  as 
follows : 
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The  lata  dictionary,  which  was  developed  in  response  to 
the  volume  analysis  of  tne  lata  case  record,  addresses  eacn 
attribute  separately  by  name,  data  type,  physical  size, 
logical  size  and  lists  the  domain  where  appropriate. 
Specifics  about  the  target  record  and  the  query  record  are 
listed  as  well  as  a  determination  of  tne  physical  record 
size.  All  tne  data  in  the  record  is  in  ASCII  character 
format;  even  items  sucn  as  tne  grid  location  and  altitude, 
which  are  actually  integer  values,  are  stored  as  characters. 
Conversion,  wnen  necessary,  is  performed  by  tne  applications 
program. 

£ .  SUMMARI 

The  primary  consideration  in  tne  design  of  tne  data  base 
was  ease  of  use  ana  speed  for  tne  user  in  tne  microcomputer 
environment.  Tnis  consideration  overrides  tne  inefficiencies 
of  a  dual  data  base  record.  Moreover,  the  complexity  of  the 
processing  requirements  is  invisible  to  tne  user.  He  is 
concerned  only  with  fast  retrieval  of  certain  types  of 
information.  As  tne  casual  user,  ne  is  not  concerned  witn 
hish  level  query  ian*ua*es  and  tneir  use.  Rather,  ne 
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requires  a  macnine  tnat  will  serve  ais  needs  ana  not  tne 
otner  way  around. 

fi.  F.  Codd,  in  nis  ia?4  article  Seven  Steps  to 
Rendezvous  wlta  tne  Casual  User  stated  tnat  "it  is  projected 
tnat  by  tne  turn  of  tne  century,  tne  majority  of  data  base 
management  systems  will  be  oriented  toward  tne  casual  user’ . 
A  system  wnicn  will  De  able  to  perform  its  function  quicniy, 
easily  and  accurately  during  tne  intensity  of  combat 
operations  will  be  tne  one  tnat  is  specifically  designed  to 
conform  to  tne  user's  environment.  Tnis  system  was  designed 
witn  tnis  principle  in  mind. 

Tne  following  cnapter  describes  tne  important 
considerations  of  tne  user  interface  and  tn?  metnoaoioey 
employed  in  maaing  tnis  interface  an  effective  one.  It 
considers  t&e  psychological  issues  wnicn  afreet  tne 
man-macnine  interface  as  well  as  tne  modes  of  user  input  and 
computer  initiated  dialogue.  Tnese  are  tne  techniques  wnicn 
enaoie  tne  target  information  system  to  conform  to  tne 
user's  environment. 
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INTERACTIVE  INTERFACE  DESIGN 


A.  GENERAL 

One  of  tne  major  design  features  or  me  target 
information  s/stem  is  tnat  it  provide  a  friendly  yet 
scpnis ti ca ted  user  interface.  It  snouid  oe  sufficiently 
sopnisticatea  to  perform  ail  of  tne  reuuiren  functions 
simply  and.  efficiently  witn  only  a  minimum  of  interaction 
from  tne  user.  Tne  environment  must  be  a  friendly  one, 

allowing  tne  user  to  recover  gracefully  and  wirn  mminum 
effort  from  error,  guiding  tne  correct  input  and  providing 
tne  user  witn  assistance  or  information  wnen  needed. 

Tne  user  is  a  Marine,  trained  in  tne  conduct  of 

supporting  arms  operations  in  a  comoat  environment.  He  is  a 
parametric  user,  a  casual  operator  of  a  computing  macnine, 
witn  no  computer  training1  ana  a  limited  capaciiity  of 

operating  a  computer.  Tne  system  must  De  sufficiently  simple 
for  tnis  user  to  learn  to  operate  it  er'fecti veiv  in  a 
■minimum  of  time  and  witn  a  minimum  of  effort.  It  must 

inspire  nis  confidence,  simplify  nis  tass,  increase  ms 
effectiveness,  reduce  or  eliminate  any  computer  "anxiety" 
and,  most  importantly,  enable  dim  to  accurately  ana  auiciriy 
carry  out  nis  mission. 

This  cnapter  outlines  tne  design  criteria  ana  tecnnioues 
used  in  determining  tne  nuaiity  of  tne  man-macmne 


interface.  Tnese  criteria  were  employed  in  tne  lesion  oi  tne 
applications  program  ar.d  constitute  its  casic  rra.mewori.  Tne 
system  effectiveness*  can  only  ce  measure!  Dy  now  wen  tr.e 
interface  oetween  tne  man  ana  tee  macame  nas  succeeaea. 
James  Martin,  in  nis  Design  of  dan-Computer  Dialogue 
descricei  tne  psychological  impact  of  tne  interactive 
interface  cn  tne  user  as  follows: 

"it  aas  oecome  increasingly  realized  mat  many 
information  processing  operations  are  nest  cameo  out 
not  by  machine  alone*  nor  oy  man  alone*  out  by  a 
judicious  comoination  of  man  and  macnine...  A  Key  to 
success  in  many  real  time  operations  lies  in  tn° 
recognition  of  machine  limitation  and  tne  ouiidine  into 
tne  system  of  appropriate  numan  capaoiiities." 

B.  DESIGN  PRINCIPLES 

Tnere  are  four  oasic  principles  used  in  tne  design  of 
tne  user  interface.  First,  it  must  be  self-explanatory.  Tne 
user  must  be  able  to  use  tne  system  witnout  reference  to  an 
external  source .  This  implies  tnat  tne  system  guice  ana 
direct  the  user  in  the  execution  of  nis  tasics  regardless  or 
nis  level  of  expertise.  This  requires  simplicity,  ease  of 
use,  and  elimination  of  system  failure.  Second,  the  syster 
must  be  self-nelping .  Waenever  tne  user  wants  or  reuuires 
help  or  assistance,  tne  system  must  responi.  It  snouii 
identify  tne  improper  input,  guide  tne  user  to  tne  crcper 
input  required  and  provide  an  example  of  tne  correct  input 
when  appropriate.  Accordingly,  °rror  messages  must  re 
explanatory  and  the  system  must  respond  to  every  input. 
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Tne  tnird  principle  is  a  requirement  for  a  simple 
interface  wi tn  tne  user.  Tne  system  must  respond  in  a  timely 
t'asnion  to  input  wnic.n  is  snort,  simple  and  oDvious  to  tr.e 
user.  Tne  processing  complexity  must  De  invisioie  to  tne 
user  for  every  procedure  of  tne  system.  T.ney  s.oouia  all 
appear  to  oe  a  straignt-f orward  and  simple  tasx. 

Tne  fourth,  principle,  previously  mentioned,  in  Cnapter 
III,  is  interaction  o.y  anticipation,  tnat  is,  anticipating 


tne 

desi  res 

of 

tne  user 

and 

presenting  nim 

w  i  t  n  a 

corresponding 

list 

of  options. 

Tnus , 

tne  system  can  avoid 

tne 

pro  blems 

Of 

employing 

erro  r 

diagnostic  and 

advisory 

messages.  Only  tnose  actions  mat  are  legitimate  are 
presented  for  user  selection.  Input  of  any  of  tne  displayed 
actions  will  result  m  a  syntactically  correct  command  ana 
allows  furtner  processing.  Input  of  an  action  otner  tnan  tne 
legitimate  one  results  in  a  simple  user  advisory  message  and 
ODviates  tne  neel  for  elaoorate  diagnosti-s  .  Tne  most  -ommor. 
type  of  dialogue  tnat  uses  interaction  oy  anticipation  is 
menu  selection  and  to  a  lesser  degree,  form  filling,  fenu 
selection  allows  tne  user  to  select  tne  desirea  option 
ratner  tnan  requiring  nim  to  specify  tnat  option. 

C.  PSYCHOLOGICAL  ISSUES 

1 .  Snort-Term  Memory  Considerations 

Our  snort-term  memory  noids  interpreted  units  of 
information  for  up  to  seconds  oefore  it  fades  away.  Witn 


continue!  exposure  to  tne  same  type  of  information, 
snort-ten  memory  retention  can  te  improve!  out  essentiaiiv, 
we  are  aDie  to  retain  oniy  a  limited  amount  of  information 
at  one  tine.  George  Miller's  classic  paper  m  lypc.  Tne 
Magical  Number  Seven — Plus  or  Minus  Two,  descrioel 
experiments  wnicn  suggested  tnat  tne  snort-term  memory  was 
limited  to  a  perception  of  aDout  seven  units.  For  terminal 
interaction,  tnis  implies  tnat  tne  processing  capacity  of  an 
individual  is  limited  to  only  a  few  items  ana  tnat  it  snouid 
oe  tasen  into  consideration  wnea  designing  menu  formats. 
Tney  snouid  be  simple,  semantically  meaningful,  arranged  in 
a  logical  progression  (to  tne  user... not  tne  programmer)  ana 
brief . 

2.  Closure 

Tnere  is  great  psycnoiogical  relief  to  snort-term 
memory  wnen  information  no  longer  needs  to  De  retained.  Tnis 
produces  a  powerful  desire  to  complete  a  tasi  witnin  tne 
snort-term  memory  span,  reduce  tne  memory  load  ana  train  tne 
psycnoiogical  relief.  Closure  is  tne  completion  of  a  tas* 
leading  to  tnis  relief.  Tne  user  expects  to  experience 
closure  after  completing  an  activity.  Any 'delay  in  acnieving 
closure  or  tne  interruption  of  tnis  process  is  frustrating. 

Tne  pressure  for  closure  implies  tnat  tne  user 
(particularly,  tne  novice  or  parametric  user)  will  prefer 
multiple  small  operations  ratner  tnan  or.e  large,  complex 
one.  In  system  design,  tnis  suggests  tnat  interactions  ce 
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aerinei  in  sections  or  logical  segments  so  mat  comoietion 
can  re  obtained  and  information  released.  All  actions  of  tne 


user  snouin  be  responded  to  in  a  positive  manner  by  tne 
system. 

6.  User  Anxiety 

Tne  user  attitude  toward  tne  computer  can  impact 
upon  nis  learning  ana  performance  w i tn  tne  system.  Computer 
"anxiety",  generated  oy  fear  of  failure,  may  reduce  tne 
user's  srort-tren  memory  capacity  and  innicit  nis 
performance.  Tne  system  snouia  put  tne  user  at  ease  out 
witnout  being  patronizing,  obvious  or  cute.  Tne  user  will 
respond  better  if  tne  instructions  are  clear,  unambiguous, 
expressed  in  familiar  terms  and  easy  to  follow.  Constructive 
advisory  messages  and  positive  reinforcement  are  preferea  to 
threatening,  condemning  or  meaningless  error  messages. 
"Fiease  reenter  your  cnoice"  is  more  user  friendly,  less 
intimidating  and  more  effective  tnar.  "nai  entry-error  dl" . 
Tne  target  information  system  nas  been  designed  to  provide  a 
comfortable,  nelpful  and  friendly  environment. 

4.  Cost  ro 1 

A  driving  force  in  a urn an  nature  is  tne  desire  tc 
control.  In  using  computers,  tne  novice  is  perfectly  willing 
to  follow  tie  computer's  instructions  and  accept  tne 
computer  as  tne  controlling  agent  in  tne  interaction.  As  nis 
level  of  experience  increases,  tne  user  may  resent  tne 
computer's  dominance  and  may  Iook  at  tne  computer  only  as  a 


tool.  Taus,  tns  system  snouia  ce  designed  to  er.nance  tne 
user  control  or  at  least  tae  appearance  cf  user  control. 
Properly  formatted  means,  advisory  messages  ana  error 
diagnostics  can  give  tae  user  tae  impression  tnat  ae  is  ir. 
complete  control  of  tne  situation.  Tae  menu  allows  aim  to 
mass  decisions  on  input  parameters  as  wen  as  selecting 
different  functions. 

D.  finS  PON  SIS  TIME 

A  simple  limit  on  response  time,  tae  time  it  taxes  fcr 
tne  system  to  respond  to  a  command,  is  desirable  for 
effective  man-macnine  interface.  An  acceptame  response  time 
is  a  function  of  tne  type  of  command  ana  tne  user's 
expectation  of  wnat  a  reasonaoie  response  time  is.  for  some 
operations,  as  is  conteat  to  let  tae  macniae  cruncn  a*ay  cut 
for  otaers,  ne  expects  an  immediate  response.  Tae  timeliness 
of  response  to  target  information  queries  was  tne  primary 
factor  for  tne  design  of  tne  dual  data  case. 

In  normal  conversation,  tne  user's  expectancy  or  a 
response  is  wltnin  aoout  two  seconds.  A  iacx  of  response 
witnin  four  seconds  would  Be  an  unnatural  Drean:  in  tne 
conversation.  In  studies  of  man-.macaiae  interface,  a 
response  witnin  two  seconds  aas  Peer,  sftown  to  constitute  an 
important  and  reasonable  Douadary  in  tne  effectiveness  of 
feedcacic.  Errors  must  oe  responded  to  witnin  two  tc  fcur 
seconds  so  tnat  tns  closure  period  is  forced  at  tne 
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appropriate  time,  w'niie  system  mitaiizatlon  may  ce 
acceptable  to  toe  user  witnin  it  seconds,  ne  experts  to 
access  tne  next  menu  or  to  receive  input  neip  airiest 
instantly,  men  tne  delay  is  expectea  to  exceed  tr.e  two 
secona  parameter,  tne  system  snoulc.  acknowledge  tne  connana 
anl  inaicate  mat  processing  is  underway  (ana  periodically 
reinforce  tnis  until  tne  process  is  complete).  Tais  ensures 
tnat  tne  user  snows  nis  cc.mmana  nas  been  acceptei  ana  tne 
macnine  is  processing  tne  request  ratner  tnan  observing  a 
bianir  screen  and  wondering  wnat  to  ao  next. 

i.  INPUT  MOTES 

1 .  Mode  Selection 

Among  tne  different  types  of  interactive  dialogues 
considered,  computer  initiated,  form  fining  aaa  menu 
selection  were  determined  to  oe  tne  most  appropriate  for  tne 
parametric  user  ana  tne  specific  application  of  target 
information.  A  combination  of  tnese  tnree  metnons  provides 
flexibility,  ease  of  use,  simplicity  and  covers  a  complete 
range  of  tne  system  functions. 

Tne  computer  initiated  dialogue,  wr.ere  tne  user  responds 
to  tne  computer,  nas  tne  advantage  or  requiring  very  littie 
training  for  tne  user  to  operate  tne  system.  However,  tne 
dialogue  can  oe  ratner  iengtny,  tne  system  can  ce  ratner 
slow  to  respond  and  mere  is  a  loss  of  flexibility  m  tne 
sequence  of  tne  dialogue.  Tne  form  filling  teennique,  wnere 


trie  user  fills  out  form  on  a  visual  aispiay  aevice,  is 
straisnt  forward  for  tn.e  operator  in  tr.at  an  r.e  needs  to  no 
is  provide  tne  appropriate  information.  Error  diagnosis  must 
oe  immediate  to  De  effective  ana  cursor  mampuia  t  ier.  must  ce 
considered . 

Menu  selection,  wnere  tne  user  selects  an  appropriate 
response  to  a  number  of  cr.oices,  reauires  little  or  no  user 
training  ana  nas  tne  advantage  tnat  tne  user  may  ce  informed 
aoout  tne  full  range  of  tne  system  features.  A  simple  exit 
from  tne  menu  sequence  and  tne  opportunity  to  return  to 
previous  menus  enables  tne  user  to  acnieve  flexibility  to 
navigate  tnrougn  tne  system.  Tne  limited  number  of  cnoices 
on  any  particular  frame  ana  tne  information  about  tne 
sequence  of  frames  wnicn  ieads  to  tne  current  one  provide  a 
narrow  context  witnin  wnicn  it  is  easy  to  design  effective 
user  aids  and  error  messages. 

Menu  selection  is  a  form  of  computer  initiated  dialogue 
since  it  Is  asirine  tne  user  a  question  and  providing  a 
limited  set  of  valid  answers.  Tne  user  determines  tne 
appropriate  input  and  tne  system  responds  witn  tne  answer  or 
anotner  menu.  Tms  contributes  Co  tne  ease  of  use  or  tne 
system  and  tne  untrained  user  can  become  proficient  in  a 
very  snort  time.  Tne  tecnnique  does  run  tne  risx  of  oem* 
too  slow  and  tedious  out  it  can  be  speeded  up  by  a  nign 
speed  terminal  and  fast  access  to  menus.  Figure  id  1  is  an 
example  of  a  menu  from  tne  target  information  system. 
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Tne  manner  in  va lcn  tne  data  is  formatted  can  affect  tne 
efficiency  of  toe  operator  oy  influencing  bo  tn  a  is  speed  and 
nis  error  rate.  A  poorly  formatted  dialogue  car.  cause 
bewilderment,  anxiety  and  improper  input.  James  Martin  i  r. 
r.is  booic,  Design  of  ^an-Computer  Dialogue.  lists  twelve 
criteria  for  tne  design  of  menu  and  form  filling  screen 
formats.  These  cri te  ria  were  used  in  tne  dcs i*n  an i 
implementation  of  tne  target  information  system: 

1.  Display  a  small  amount  of  information,  at  one  tire 

2.  Do  not  include  unwan t ea/unneeded  information 

3.  Have  one  idea  per  display 

4.  The  operator  response  snouli  be  sncrt 

5.  Tne  computer  should  always  respond  to  the  operator 

5.  Use  formats  desisrned  for  clarity 

7.  Strive  for  similarity  (position,  format,  terms) 

3.  Avoid  difficult  words  or  cnaracters 

9.  Provide  an  easy  means  for  correction 

13.  yaie  i  r.s  t  rue  t  i  cns  to  tne  operator  stand  out 

11.  Clean  up  the  screen  wnen  possible 

12.  va.<e  it  easy  for  tne  operator  to  asi  for  help 

S.  E .  Enele  and  H .  E.  Crania  ir.  their  «or!£,  G  ui  del  1  r.e  s 
for  Var./Display  Interface,  mention  many  different  and  useful 
techniques  for  improving  the  interactive  dialogue  ar.d  the 
user  input.  Some  of  tne  more  important  points  used  ir  tne 
desian  of  the  target  information  system  are  paraphased  in 
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me  following  list  : 

A.vcic.  aboreoiations  d aa  contractions 

Be  consistent  in  use  ana  meaning  of  tscr.nical  words 

Use  examples  to  supplement  lost  ructi  or.s 

Be  consistent  in  presenting  identicai/similar  lata 

Use  numbers  wnen  listing  selectable  iters 

Place  most  prooaoie  iters  at  tna  top  of  tne  Ter.u 

Standardize  screen  organization  and  fcrr.at 

Give  user  directions  before  tne  list  of  cnaice? 

User  input  snould  be  Kept  to  a  minimum 
Present  data  in  a  recognizable  order 
Avoid  verbosity  and  wordiness 

F.  ERHOH  HANDLING 

Well  designed  diagnostics  and  error  messages  can  guide 
tr.e  user  to  enter  tne  correct  commands.  7ner.  tr.e  system 
prompts  tne  user  tnat  an  error  nas  occurea,  it  snould  allow 
for  error  correction  immediately.  In  tne  menu  selection 
dialogues,  tne  range  of  options  is  predetermined  tv  tne 
system  and  only  a  valid  input  will  result  in  tne  appropriate 
closure.  Invalid  inputs  can  be  .easily  determined  and 
appropriate  guidance  provided  to  tne  user  in  tne  error 
message  to  obtain  tne  proper  input. 

Form  filling  dialogue  can  cnecir  tne  field  ieru'tn  and 
field  type  (for  example,  a  grid  location  would  consist  of 
eignt  numbers  and  any  otner  input  would  be  invalid).  Error 
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A.  SYSTEM  IMPLEMENTATION 

Phased  on  tne  lesion  criteria  outlined  in  'Capture  17. 
and  71,  tne  target  information  system:  was  coded,  compile 
and  tested.  Eacn  module  was  coded  i naependent ly  of  tne  ctne 
ann  tested  ir.  its  own  environment .  Similarity  of  tr. 
interface  was  maintained  between  eacn  module  and  was  tr 
first  part  of  eacn  module  coded.  After  tne  interface  «as  i 
place  and  worsins,  tne  module  was  filled  out  to  perforr  tr 
system  functions.  After  eacn  module  was  tested  and  ietyeve 
independen tly ,  it  was  incorporated  into  tne  sys tew  »r.er 
additional  testing  and  debugging  tooa  place.  Tne  nett  modui 
was  tnen  coded  after  tne  system  was  functioning  properly. 

Tne  Interface  module  is  tne  main  system  program  ar. 
contains  tne  global  data  structures  anu  tne  system,  pri-itiv 
routines  sucn  as  clearing  tne  screen,  snipping  lines,  ar. 
printing  error  messages.  It  maies  tie  coils  to  tne  Sfg'er. 
procedures  from  a  master  menu.  Anotaer  primary  function  c 
tnis  module  is  to  build  tne  address  map  of  tne  records  a 
tne  start  of  eacn  session  and  to  open  tne  system  data  files 
Tnis  module  compiled  to  61Hi£  bytes  ex'  obj°ct  cone  onion  i 
four  S  less  tftan  originally  expected. 

Tne  first  of  tne  segment  routines  is  tne  Inform  module 
Tnis  module  contains  system  operating  instructions 


doctrinal  explanations  of  target  information  ter^s,  target 
analysis  guidelines,  security  requirements  ana  examples  of 
formats  used  in  tne  system.  It  is  basically  all  text  and 
serves  tc  inform  tne  user  of  tne  capaoilities  of  tne  system. 
Tne  module  compiles  to  1 7,322  bytes  of  CDject  cole. 

Tne  Initialize  module  is  designed  to  erase  tne  current 
data  files  and  completely  reinitialize  tne  system.  It 
performs  no  otner  function  for  tne  system.  It  tuilis  tne 
data  files  to  tne  reouirei  size  and  fills  tne  file  witn 
empty  records.  It  compiles  to  25 22  bytes  of  object  code. 

Tne  tnird  seement  procedure  is  tne  Target  module.  It 
contains  suD-modules  for  addins  a  target,  deleting  =  target, 
cnansins  current  tareet  information,  iisplayins  a  target  aM 
ailing  a  BHA  to  tne  target  record,  major  difficulties  were 
encountered  in  loading  tills  very  large  module  and  its 
involved  user  interface  into  main  memory  witn  tee  operating 
system  cole  and  tne  system  Interface  module.  Initial 
compilation  of  tne  module  was  to  36,422  bytes.  Tne  ^ain 
problem  was  tne  amount  of  text  tnat  tne  user  interface  was 
consuming.  One  screen  frame  of  user  information  (advisories, 
explanations,  etc.)  usually  toos  1222  bytes  of  object  cole. 
Tne  expense  of  so  muen  text  m  tne  code  was  m.uca  too  great 
for  tnis  module. 

Conseouently ,  a  decision  was  made  to  reduce  tne  size  of 
tne  module  by  putting  most  of  tne  text  in  separate  text 
files  on  tne  diskette  and  retrieving  tries e  fixes  from 
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secondary  storage  wrier,  canea  27  tne  program.  Tms  produced 
two  unpleasar.  t  sil?  effects.  Pi rs  ? ,  roe  irt-rfsce  » as  sic  wee 
consiaeratiy  since  it  row  too*  longer  to  piece  a  user 
message  on  tne  screen  (aitneugn  tae  user  could  not  read  as 
fast  as  tne  output'  and  second,  tne  diskette  now  contained 
numerous  text  files  in  addition  to  tne  cone  and  data  files 
snown  in  figure  7. 

Since  tne  Pascal  system  used  four  ciocks  of  512  oytes 
earn  for  a  text  file  no  matter  now  small  tne  file  was,  tne 
54  text  files  too*  approximately  IliJ  £  oytes  of  secondary 
storage.  This  caused  tr.e  system  to  employ  tne  second  ALTOS 
disic  drive,  wnlcn  nad  not  teen  used  nrevmusi  v .  Tne 


resul tan  t 

reconfieura  tion 

of 

tne 

secondary  storaec 

allocation 

is  snown  in 

figure 

23. 

Certain  menus  and 

recurring  messages  were  retained  in  tne  target  modul-  to 
speed  tne  processing  and  decrease  user  wait  time. 

Tne  use  cf  tne  text  files  and  tne  re  orsranl  xa  t  i  on  cf  tne 
3 DA  routine  into  a  separate  segment  procedure  (called  ty  tne 
Target  segment  procedure),  reduced  tne  module  tc 
Oytes  of  oeject  code  (19,3k'D  oytes  wnen  tne  bZ A  procecure  is 
called).  Tnis  proved  a  satisfactory  solution  witnout  a 
significant  design  cnange.  Tne  direct  access  capatility  of 
tne  Pascal  system  proved  ootn  accurate  and  fast  witr.  r,c 
apparent  wait  in  tne  process  time  tetween  a  reouest  for  a 
record  and  a  reply  to  tne  CRT. 
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is 
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to 
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logical  "ANDING"  of  el 

ements  of  tne  lonai 
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ol'  tne  record,  tne  array  nro cessi n?  proved  to  ee  very  rapid 
and  well  witnin  tne  two  second  time  response  parameters. 
Loading  of  tne  data  case  query  file  was  straignt  forward  ar.d 
cranges  in  tne  main  record,  performed  in  tne  target  module, 
were  being  correctly  reflected  in  tne  data  case  query  file. 
Wnile  initial  evaluation  of  tde  module  proved  satisfactory, 
it  is  felt  tnat  system  improvement  could  be  obtained  tv 
designing  an  interface  and  an  algorithm  wnicr  allowed  noth 
logical  "ANEING"  and  "ORING”  of  attributes.  Tnis  segment 
procedure  compiles  to  S2£(£  bytes  of  object-  cone. 

Tne  final  segment  procedure,  tne  Utility  module,  nas  net 
been  completely  implemented  due  to  programming  time 
constraints.  Eowever,  tne  complete  user  interface  is  in 
place  and  operational  and  gives  tne  user  tne  impression  tnat 
tr.e  system  is  operating.  Tne  erase  file  function  is 
operational  and  worses  effectively.  Tr.e  following  functions 
nave  not  been  implemented:  cnangine  tbe  password  (requires 
design  of  tne  password  record  as  well  as  implementation), 
copying  tne  data  base  query  and  target  files  to  a  oacitup 
diskette,  operations  on  tne  7AR3UL — displaying ,  renumbering , 


printing  and  reinitiating  (tnis  also  requires  design  of  tne 


TASBUL  record),  printing  target  cards  ar.d  lists  and  tne 
■'cmputa  tion  anl  display  ot  target  file  statistics.  Tne 
current  size  of  tne  monuie  is  IB , 3iit5  cvtes.  A s  functions  are 
aided  and  tr.e  size  increases,  *1100  of  tne  user  interface  can 
oe  transfered  to  text  flies  to  seep  tne  size  of  tne  roduie 
at  an  acceptaoie  level. 

Tne  entire  pro?ram  compiles  to  72  K  of  ocject  coce,  56 
of  wnicn  is  contained  in  segment  procedures.  Toe  system 
source  code,  wnicn  is  contained  in  tne  Naval  Postgraduate 
Scaool  tecnnical  report  entitled  A  Prototype  Program  for 
Target  Information  { iNPSSZ-ei-fe-?) .  is  over  52?*  lines  ion?. 
Initial  testing  and  implementation  was  do^e  witr.  a  target 
list  size  of  1C2  tarsets  and  later  expanded  to  tr.e  required 

target  maximum.  It  r.as  been  debugged  for  execution  and 
tested  for  operational  accuracy.  .Vnile  initial  results  are 
very  satisfying  and  tne  system  proves  fast  ana  accurate, 
extensive  testing  to  include  field  testin?  would  be  reuuirea 
before  tne  system  could  become  operational.  Addi tic nai ly , 
tne  Utility  module  would  nave  to  oe  completed. 

Tnere  are  two  main  concerns  in  testing  tne  system. 
First,  tnat  it  meets  tne  requirements  of  tne  target 
information  section  and  effectively  accomplisnes  its 
purpose. .. tee  automation  of  tne  target  information 
functions,  and  second,  tnat  tne  user  interface  is  as 
effective  as  it  proports  to  be.  Tnis  will  require  extensive 
testing  ana  validation  as  well  as  operational  testing  and 


evaluation  in  appropriate  tactical  command  post  exercises 
wnicn  employ  tee  division  or  tne  yAB  fire  support 
coordination  center. 

B.  TECHNICAL  CONSIDERATIONS 

Tne  Pascal  program  listed  in  tne  tecnnica 1  report  is 
transportable  to  ot.ner  UCSD  Pascal  systems  ard  witn 
modification  (random  access,  segment  procedures,  strings'  to 
any  Pascal  system.  Certain  aspects  of  tne  program  were 
irpie-nented  to  conform  to  tne  Datamedia  Elite  25C0  video 
terminal.  T.nls  terminal  nas  80  cr.aracters  per  line  witn  24 
lines  of  display  wltn  full  upper  and  lo»er  case  ASCII 
operating  at  a  data  rate  of  9600  baud.  It  .nas  a  1920 
cnaracter  screen  capacity,  an  aipnanumeric  Keyboard  ar.d 
display  and  ootn  synenronous  and  asynchronous  interface. 
So">e  of  tne  special  cnaracters  used  in  tne  program  include: 


ASCII 

Decimal 

Function 

SO 

14 

biinlr  field  on 

CAN 

24 

oiint  field  of 

BEL 

? 

bell/oeeper 

OS 

29 

roll  field  or. 

US 

31 

clear  screen 

It  Is  recognized  that  tne  design  and  implementation  is 
based  on  tne  ALTCS  ACS  3000-1  '  computer.  Advances  in 
microcomputer  technology  will  invariably  modify  the 
environment  for  wnlcn  tne  prototype  was  designed.  Tne 
addition  of  nard  disic  capabilities  to  microcomputer  systems 
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will  increase  tne  secondary  storage  space  as  well  as  tne 
processing  speed  now  availabi°  witr.  floppy  diskettes.  To* 
current  system  can  certainly  function  effectively  in  sues  a 
new  environment  but  tne  possibilities  cf  redesign  snouid  be 
considered  if  tne  increase  in  efficiency  is  warranted  and 
tne  tine  span  between  a  new  implementation  and  tne 
introduction  of  /IPASS  is  sufficiently  long. 

Since  tne  ’JCSD  Pascal  is  available  on  so  many  systems. 


w i t  n  tne 

proper  setup  routines  tne 

system  i 

s  sufficiently 

portable 

provided  tne 

secondary 

s  t  OTaSe 

capability  is 

available 

.  Tne  source 

code  is  c 

ompiiatie 

or.  personal 

computers 

sues  as  tne 

Apple  II  wden  tne  Pascal  system  card 

is  included  witn  a  34 

K  memory 

aitaougn 

tne  size  of 

secondary 

storage  (tne 

Apple  uses 

a  5  1/4  i 

non  mini -floppy 

diskette) 

will  dictate  a 

realignment 

of  files 

and  a  former 

partitioning  of  system  software. 

C.  TACTICAL  CONSIDERATIONS 

Tnere  are  a  number  of  considerations  wnicr.  involve  tne 
tactical  and  operational  aspects  of  target  information  wdi-n 
bear  consideration  out  weien  are  beyond  tne  scope  of  mis 
tne sis.  Tne  first  of  tnese  is  tne  survivability  cf  tne  ALTOS 
and  related  equipment  in  tne  field.  Special  nandlirg  and 
care  is  required  of  eacn  item  as  well  as  tne  system  ar.i 
target  diskettes.  Specific  instructions  for  tne  user  in  tne 
maintenance  and  dandling  of  tne  system  must  be  determined 
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and  promulgated  to  tr.e  user.  Additionally.  ~  e  r 
requirements  and  tr.e  resultant  equipment  modi  fi catlo r. s  or 
adjustments  reeded  to  operate  in  a  field  e  nvi re  rm°n  t  must  re 
considered. 

Tne  acauisition  and  use  of  tr.is  equipnent  may  ce  cause 
to  examine  tne  tames  of  organization  to  de te re ”ir.e  tne 
proper  staffing  of  tne  target  information  section  since  a 
reduction  of  personnel  seems  ratner  =asy  to  acri-ve. 
Additionally,  a  metnod  of  transfering  data  from  tr.e  Navy 
ASIS  computer  to  tne  system  microcomputer  sr.ouid  re 
investigated  and  addressed  since  transfering  tr.e  lata 
electronically  between  tne  two  systems  is  preferable  to 
manually  transfering  tne  lata  into  tne  microcomputer  system. 
Concept  of  employment  of  tne  system  aboard  snip  (in  SACC  or 
in  landing  force  spaces^  must  also  re  determined  and 
promulgated . 

Once  adopted  and  functional,  long  range  mans  must  re 
determined  for  a  transition  from  tne  system  to  tne  V'IFAS5 
system.  These,  of  course,  are  locally  generated  reouirener.ts 
and  can  ce  addressed  in  tne  future.  It  is  anticipated  tne 
."ilFAoS  will  require  extensive  operator  training  tefere  it 
becomes  operational  wnereas  tne  microcomputer  prototype 
system  reauires  only  user  familiarization.  It  is  estimated 
tnat  tne  user  can  become  proficient  witn  tnis  system  after  a 
one  aour  familiarization  period. 


Tne  requirements  i  or  mainta  ini r.s  a  ?rapnical  aispxa/  cf 
carpets,  walls  currently  soivacie  wita  computer  *rapnics, 
will  continue  to  ce  accomplished  by  the  use  of  ta-tiral 
cattle  maps  covered  witn  acetate  overlays  wr.ere  tne 
situation  dictates.  Tnis  system  maices  no  attempt  tc  acuress 
tne  srrapnic  display  of  targets.  It  is  felt  tnat  tne  display 
capabilities  cf  tne  MIFASS  system  will  adequately  satisfy 
tne  requirements  wnen  tne  system  is  introiu'-el  into  tne 
fleet. 

D.  SYSTEM  REFINEMENTS 

Vnile  tne  system  meets  all  tne  requirements  identified 
for  tne  target  information  section,  tnere  are  a  number  of 
refinements  to  tne  program  wnicn  could  ce  inpie^ertec  in  a 
later  version  cf  tne  prototype  wnicn  would  enhance  tne 
system  performance  and  provide  additional  capabilities  to 
tne  TIO.  Tnese  include  tne  following: 

1.  Expanding-  tne  size  of  tne  target  file  teyoni  the 
current  2Zki  target  maximum  if  tne  tactical  considerations 
of  future  battle  scenarios  dictate. 

Z.  Logical  "ORING"  and  "ANTING "  of  record  attritute 
domains  in  tne  tuery  module  to  provide  a  more  refined 
selectivity  of  tne  special  target  lists. 

3.  Inclusion  of  a  utility  routine  in  tne  query  module  tc 
print  tne  tarset  list  obtained  as  a  result  of  tne  query. 
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4.  Mlcw  trie  user  to  specify  altitude  ir.  feet,  yarn s  :  r 
re ters  and  nave  t  ne  sys  ter  convert  tne  lata  to  re  tens . 

5.  Pind  tne  number  and  assignations  of  targets  witr.ir  a 
certain  radius  or  distance  of  anotr.er  target  (for  exampi’, 
a  class  i!  target)  or  a  *nown  grid  reference  point. 

5.  Provide  a  routine  for  seeping  tracK  of  tr.e  next 
available  target  number  from  tne  FZCC  oioc<  of  target 
numbers . 

7.  Modification  of  tne  !TC  SD  Pascal  operating  system 
command  prompt  to  allow  tne  user  only  one  o.boioe  of 
option,  i.  e.,  to  run  tne  system  program  and  remove  tne 
filer  subroutine  from  nis  environment. 

B.  Plotting  of  artillery  firing  units  and  naval  gunfire 
support  stations  to  determine  automatically ,  wnicb  targets 
are  witnin  tne  effective  range  of  specific  supporting 
arms. 

y .  Reduction  ox  ~odi ng  cy  improved  algorithms  and 
subroutines. 

1 Z .  Pro vi de  operator  training  ani  system  maintenance 
manuals  for  tne  system. 
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Till  COCCUS  IONS  AND  RLCOMMiNDAT  I  J.\S 


A.  CONCLUSIONS 

Tni  s  me  sis  nds  contended  tnat  me  opera  ticca* 
effectiveness  of  tee  fire  support  coordination  center  «cu:2 
re  improved  cy  me  automation  of  tee  t a~.ee t  fr.fo~'n  =  ti  j  r. 
function.  Partner,  it  appears  tnat  tne  lesion  and 
implementation  of  a  suite  tie  ana  effective  system  is 
pcssiDls  now,  five  full  years  oefore  tne  introduction  of  tne 
YIFASS  computer  system  into  tne  Fleet  Marine  Forces. 

Tne  tnesis  nas  presentee,  one  suen  design  using  a  rata 
Base  approac.n  on  a  typically  met' i ?ured ,  commercially 
avaiiacie  microcomputer  witn  a  user  interface  specifically 
designed  for  tne  Marine  performing  tr.s  target  information 
functions  in  an  operational  environment.  Ar.  evaluation  of 
tne  implemented  prototype  vIcrocompute r  System  for  Target 
Information  (*ISTI)  nas  determined  tnat  tne  requirements  ar.c 
specifications  for  tne  system  as  iesericec  in  cr.apters  II 
and  III  nave  oeen  met  and  tnat  tne  program  operates 
effectively  and  efficiently. 

Tne  Basic  soundness  of  tne  iesien  is  reflected  in  torn 
tne  operational  effectiveness  of  tne  prototype  and  tne  laci 
of  significant  cnanees  or  modiiicaticns  neeiel  to  meet  tne 
stated  system  requirements.  Tne  wording  prototype,  if 
employed  in  an  FSCC  in  its  present  state,  would  immediately 
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increase  tr.e  operational  effectiveness  of  tne  target 
i  r.f  or-1?  ti  cr.  section. 

r.  aSCOMKNEATICNS 

Tne  design  and  itrpiementa  tion  nas  been  s.oc*r.  to  De  scum 
am,  based  on  tne  observed  effectiveness  or  tm  prototype 
program,  tne  following  recommendations  are  naae: 

i.  Tnat  tr.e  implementation  of  tne  prototype  Microcomputer 
System  for  Target  Information  (VISTI)  ce  continued  in 
accordance  «itn  tne  lesion  criteria  outlined  nereis  and 
tne  system  refinements  discussed  in  ccapter  VII. 
d.  Tnat  tne  resultant  system  be  tested  and  evaluated  at 
selected  Marine  Corps  commands  to  determine  its 
effectiveness  in  actual  tactical  operations. 

3.  Tnat  tne  marine  Corps  adopt  tne  microcomputer  System 
for  Target  Information  (MISTI)  cn  an  interim  basis  until 
tne  introduction  of  tne  vIFA3Sj  system. 

4.  Tnat  appropriate  nardware  and  software  dp  provided  t: 
tr.e  tnree  Marine  Division  fire  support  -ocrdir.atior. 
centers  in  order  to  employ  tnis  system. 

a.  Tr.at  tne  Marine  Corps  Tactical  Software  Support 
Activity  (V,CTSSA)  evaluate  tne  Microcomputer  System  for 
Tareet  Information  (MISTI)  as  a  testbed  model  for  tr.e 
software  interface  criteria  of  tne  target  information 


portion  of  me  MIFASS  system 


c  y  t  e  s 


I 


i 


K 

; 


At tri cutes  ier.r-in :  43 
Tame  sec  size:  153 
lea?tr:  fixed 


Attribute  list: 

(Ta 

Target  Pftcora 
r?et  Query  ?.e/' 

and  Tar=;e t 
ord  ait ri but 

Query  "e no rn 

as  i  a  i  i  -  a  t  e  i  r. •••' ' 

A.TTH  I5(JT? 

x-  r1  r-  r*  r*  T  ^  »' 

u  *-*  w  c  *%  x  c  *  Xw.« 

STTRi'T  a" 

-  -  “  =  I  'J 

^Tar^et  nun  car 

2  cnar.  4  ir.t 

6  cnar 

A.w  i-ri-zzvasy 

vGrid  location 

5  ir.t 

c  c  a  a  r 

r.ureri  cal 

*  A 1 1  i tuae 

±  i  at 

~  cnar 

3  < * t  —  j  y  4  y 

vDesc  ri pti cn 

4  Z  cnar 

4“  £  c  n  d  r 
*2?  : n s r 

s  trine: 

P.e-na  rss 

4 it  cnar 

4  3  cnar 

s  t  r  i  n  =■ 

’"Classification 

1  c  a  a  r 

1  cr.ar 

«  r*  -r>  7 

A*  0/  »  *  — 1 

*?.vpe 

4  cnar 

1  caar 

m  «  ••  V  r  C  ^ 

'C  *  T  T'1?'** 

C  url/%  x  it  ^  i  • 

C?.  TihF.  72F, 
FCr.  T ,  C  3 4  T 

rio ri ty 

3  cnar 

1  cnar 

I.  II,  III,  17 

^Status 

3  cr.ar 

1  cnar 

1CT17  3  IN  ACT  ITS 

’"Supportin?  ir 
assigned 

4  cnar 

1  c  n  d  7 

A I F  ,  AF TY  •  N 3-F 

i  a* 

^  x  r...  ,  wi*  - 

DIG  surveiii an~® 

6  int ,  i  c  b.a  r 

7  caar 

iliZi 1A-312353? 

firing  unit 

6  cnar 

f?  caar 

string 

No. /type  rounds 

1Z  cnar 

13  .mar 

stria? 

Canape  assessel 

11  cnar 

1  cnar 

Danae®  reported 

11  cnar 

1  cnar 

Interdicted. 

neutralized,  illuminated, 
damaged,  destroyed, 
unknown ,  uno r served , 


V  ^ 
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APPENDIX  B  -  EXAMPLE  OF  SYSTEM  USER  INTERFACE 


This  appendix  illustrates  tne  menu  selection  format  of 
tne  user  interface  explained  in  detail  in  tne  preceeding 
chapters.  It  simulates  tne  user  operating  tne  query  module 
and  forming  a  list  of  targets  for  a  special  listing.  Tne 
fire  support  coordinator  nas  assed  tne  target  information 
officer  for  a  list  of  targets  whicn  are  to  be  considered  in 
tne  formulation  of  a  flat  suppression  fire  plan  prior  to  tne 
calling  of  close  air  support  aircraft  on  an  important 
landing  force  target. 

Essentially,  tne  list  must  include  all  targets  from  the 
following  categories: 

Type . SEAD  targets 

Classification.  ...all  classes 

Priori  ty . I 

Status . active  targets 

Accuracy . all  categories 

Supporting  arm . . . .artl llery 

The  example  simulates  the  user  interface  of  actual 
system  operation  to  complete  tnis  query  as  specified  aoove. 
Each  page  represents  a  separate  frame  observed  by  tne  user 
on  tne  CRT  screen. 
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SPECIAL  TARGET  LISTINGS 

The  options  are: 

1. 

Form  a  special  target 

listing 

2. 

Continue  to  process 

3. 

tfrite  tne  special  list 

to  tne  screen 

4. 

Information  acout  tnis 

procedure 

5. 

Return  to  previous  menu 

PLEASE 

ENTER  OPTION  NUMBER 

Tne  user  enters  option  1 
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Categories  for  Special  Listing 


The  listing  can  contain  6  items  from  the  below  menu 

1.  Target  type 

2.  Classification 

3.  Supporting  arm  assigned 

4.  Priority 

5.  Accuracy 

6.  Status 

*  P.  Process  information 

Special  list  currently  contains  0  targets. 
Please  start  a  new  listine. 

PLEASE  ENTER  OPTION  NUMBER 


User  enters  option  l  to  select  tne  tarset  type 


ENTER  TARGET  TYPE 
Tae  options  are: 

1.  Tank 

2.  SEAD  tareet 

3.  Installation 

4.  Counter  Battery 

5.  Observation  Post 

6.  Terrain 
?.  Fenicles 

8.  Fortifications 

9.  Miscellaneous 

PLEASE  ENTER  OPTION  NUMBER 
==> 


L 


User  enters  a  2 


for  tne  SEAD 


targets 
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Categories  for  Special  listing 

Tne  listing 

can  contain  b  items  from  tne  oeiow  menu: 

1. 

Target  type  Already  Tairen 

2. 

Ciassif ication 

3. 

Supporting  arm  assigned 

4. 

Priority 

5. 

Accuracy 

6. 

Status 

*  P. 

Process  information 

Special 

list  currently  contains  42  targets. 

please  enter  option  number 
==>_ 

user  enters  option  3  to  select  tne  supportine  arm 


L3; 


ENTER  SUPPORTING  ARM  ASSIGNED  TO  TARGET 


Tne  options  are: 

1.  ARTY 

2.  NGF 

3.  AIR 

4.  AIR,  ART! 

5.  AIR,  NGF 

6.  ARTY,  NGF 

?.  AIR,  ARTY,  NGF 

8.  Otner 

9.  None 

PLEASE  ENTER  OPTION  NUMBER 
==> 


User  enters  option  1  to  select  artillery 


Categories  for  Special  Listing 

Tne  listing 

can  contain  4  items  from  tne  below  menu: 

1. 

Tarsret  type  Already  Taien 

2. 

Classification 

3. 

Supporting  ant  assigned  Already  Taiten 

4. 

Priori ty 

5. 

Accuracy 

e>. 

Status 

*  p. 

Process  information 

Special 

list  currently  contains  29  targets. 

please  enter  option  number 

User  enters  option  4  to  select  tne  target  priority 


ENTER  TARSET  PRIORITY 


The  options  are: 

1.  I 

2.  II 

3.  Ill 

4.  IV 


PLEASE  ENTER  OPTION  NUMBER 


User  selects  option  1  for  priority 


target 
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Categories  for  Special  Listing 


1  is  tl ng 

can  contain  3  items  from 

tne  oeiow 

menu : 

1. 

Target  type 

Already 

Tatten 

•-> 

w  • 

Classification 

3. 

Supporting  arm  assigned 

Already 

Taiten 

4. 

Priority 

Already 

Ta  Aen 

5. 

Accuracy 

6. 

Status 

*  P. 

Process  information 

Special 

list  currently  contains 

16  targets 

1  • 

PLEASE  ENTER  OPTION  NUMBER 
==> 


User 


enters  option  6  to 


select 


trip  target  status 
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ENTER  TARGET  STATUS  —ACTIVITY 
Tae  options  are: 

1.  Active 

2.  Inactive 

PLEASE  ENTER  OPTION  NUMBER  AND  PRESS  RETURN 
==> 


User  selects  option  l  for  active  targets 
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Categories  for  Special  Listing 

The  listing 

can  contain  2  items  from 

the  below 

menu: 

1. 

Target  type 

Already 

Taicen 

2. 

Classification 

3. 

Supporting  arm  assigned 

Already 

Taiten 

4. 

Priority 

Already 

Taicen 

5. 

Accuracy 

6. 

S  tatus 

Already 

Taten 

*  P. 

Process  information 

Special 

list  currently  contains 

10  targets 

« 

PLEASE  ENTER  OPTION  NUMBER 

User 


has  completed  the  query  and  now 
process  the  list  of  10  tareets 


elects 


to 
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SPECIAL  TARGET  LISTINGS 


The  options  are: 

1.  Form  a  special  tareet  listing 

2.  Continue  to  process 

3.  Write  the  special  list  to  the  screen 

4.  Information  about  tnis  procedure 

5.  Return  to  previous  menu 


PLEASE  ENTER  OPTION  NUMBER 


Tne  user  selects  option  3  to  dlsoiay  tne  llsti... 
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SPECIAL  TARGET  LISTINS 


Categories : 

SEAD  ACTIVE  Prl 

I  ARTY 

TGT  NO 

CL 

PRI 

LOCATION 

alt 

SA 

DESCRIPTION 

AA0046* 

A 

I 

35647582 

100 

ARTY 

2  ZSU-23  PLT 

AA0057* 

C 

I 

35452353 

60 

ARTY 

SA-6  CLUSTER 

AA0078 

A 

I 

35467787 

50 

ARTY 

12.5  AAA  SITE 

AA0156* 

A 

I 

35667746 

120 

ARTY 

S-60  PLT  IN  OPEN 

AA0122* 

D 

I 

35334563 

25 

ARTY 

SA-9  PLT  IN  TREES 

AA0144* 

E 

I 

35674664 

50 

ARTY 

14.5  AAA  SITE 

AA0167 

A 

I 

35455234 

100 

ARTY 

ZU-23  AAA  CLUSTER 

NA0023* 

D 

I 

34556867 

20 

ARTY 

120  MM  AAA  CANNON 

AA0186* 

C 

I 

34567890 

150 

ARTY 

SA-8  IN  BUNKERS 

AA0194* 

A 

I 

36087546 

45 

ARTY 

S-60  AAA  CLUSTER 

NOTE:  *  indicates  target  list 


PLEASE  PRESS  RETURN  TO  CONTINUE 

«> 


J 


The  user  presses  RETURN  to  continue 
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SPECIAL  TARGET  LISTINGS 


Tne  options  are: 

1.  Form  a  special  tareet  listing 

2.  Continue  to  process 

3.  Write  tne  special  list  to  tne  screen 

4.  Information  about  tftis  procedure 

5.  Return  to  previous  menu 

PLEASE  ENTER  OPTION  NUMBER 
«> 


Toe  user  begins  a  new  query  or  returns  to  tne  main  menu 
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